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I  INTRODUCTION 


I  INTRODUCTION 


•  This  report  was  prepared  by  INPUT  as  a  custom  study  for  GTE  Service 
Corporation,  Stamford,  Connecticut. 

•  Tine  primary  objective  of  the  study  was  to  describe  the  software  development 
procedures  of  computer  manufacturing  corporations  who  produce  small-  and 
medium-sized  freestanding  systems. 

•  Information  for  this  study  was  obtained  from  several  sources: 

On-site  interviews  with  eight  computer  manufacturers. 

Telephone  interviews  with  13  computer  manufacturers. 

Review  of  INPUT'S  files  and  previous  studies  on  the  subject  of  software 
development  and  maintenance. 

0  The  21  companies  interviewed  had  annual  revenues  of  approximately  $24 
billion,  of  which  about  $12  billion  was  derived  from  the  sale  of  computer 
systems  and  software.  A  profile  of  the  companies  interviewed  and  their 
organizational  charts  are  in  Appendices  A  and  C. 

•  These  companies  represent  almost  half  of  the  computer  manufacturers  in  the 
United  States. 
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•  Many  of  the  interviewees  had  total  responsibility  for  the  development  of 
software  for  their  connpany's  connputer  products  while  others  were  responsible 
for  a  major  division  or  product  line.  Titles  of  the  people  interviewed  included: 

Section  Manager,  General  Systems  Division. 
Director,  Advanced  Systems  Development. 
Manager,  Language  Processor  Group. 
Manager,  Technical  Release. 

Director  of  Network  Engineering  and  Software  Development, 
Vice  President,  Software. 

Manager,  Software  Engineering,  Advanced  Products. 
Engineering  Manager  (Software). 
Manager,  Systems  Engineering. 
President. 

Director  of  Software. 

Manager,  Systems  Software  Development. 

General  Manager,  Division. 

Vice  President,  Product  Development  (Software). 
Industry  Systems  Software  Manager. 
Product  Engineering  (Software)  Manager. 
Director  of  Programming. 
Director  of  Software. 
Manager,  Basic  Software. 
Director  of  Software. 
-  .      Director,  Software  Products. 

•  None  of  the  managers  interviewed  was  responsible  for  in-house  data 
processing  or  Management  Information  Systems. 

•  Although  the  companies  interviewed  represent  a  large  percentage  of  the 
computer  manufacturing  industry,  the  data  reported  on  in  this  study  cannot  be 
considered  statistically  reliable  due  the  small  sample  of  companies  inter- 
viewed and,  for  many  specific  questions,  the  even  smaller  amount  of  data 
obtained. 
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•  Nevertheless,  the  information  and  analysis  is  considered  very  useful  in  that  it 
does  give  strong  indications  in  many  cases  about  factors  affecting  the 
development  and  maintenance  of  computer  software. 
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i I   EXECUTIVE  SUMMARY 


II        EXECUTIVE  SUMMARY 


A.       MAJOR  FINDINGS  AND  CONCLUSIONS 

I.        EFFECTIVE  SOFTWARE  ORGANIZATIONS 

•  The  software  development  organizations  of  21  companies  were  interviewed, 
analyzed  and  evaluated. 

•  A  methodology  was  developed  for  evaluating  the  software  development 
organization's  effectiveness  and  productivity  based  on  an  assessment  of  the 
software's  market  acceptance,  profitability,  quality,  reliability  and  mainte- 
nance cost. 

•  The  companies  were  rated  on  a  scale  of  I  to  ^,  where  I  was  the  least  effective 
organization. 

All  of  the  companies  that  received  the  same  rating  were  assigned  to  the 
same  group,  which  was  numbered  according  to  the  rating  received. 

The  companies  in  Group  I  clearly  out-performed  the  companies  in 
Groups  II,  III  and  IV  by  every  criteria  of  success  applied  to  the  company 
and  its  software  development  organization. 
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The  number  of  companies  in  each  group  and  a  description  of  the  rating  of  each 
group  are  shown  in  Exhibit  II- 1. 


SOFTWARE  DEVELOPMENT  AND  CORPORATE  ORGANIZATION 
a.        Reporting  Structure 

Seventy-five  percent  of  the  directors  of  software  development  reported  to 
second  level  management,  while  25%  reported  to  the  first  levels. 

A  majority  of  the  directors  reported  to  the  research  and  development  vice 
president,  and  the  balance  reported  to  either  the  division  manager  (or 
president)  or  the  marketing  vice  president. 

More  than  sixty  percent  of  the  companies  had  a  project-oriented  organization, 
with  the  remainder  evenly  divided  between  function  and  matrix  organizations. 

The  above-average  companies  favored  project  orientation  first  and  matrix 
second;  none  was  functionally  organized. 

Many  of  the  companies  had  separate  software  groups  dedicated  to  advanced 
systems  development. 

Some  of  the  companies  had  internal  consultants  who  acted  as  advisors  on 
software  technology  to  senior  management. 

A  substantial  difference  was  found  between  the  groups  on  the  issue  of  separate 
maintenance  functions. 

Eighty-three  percent  of  the  Group  I  companies  separated  maintenance 
functionally. 

Only  20%  of  the  Group  II,  III  and  IV  companies  separated  development 
from  maintenance. 
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EXHIBIT  ll-l 


RATING  OF  THE  OVERALL  EFFECTIVENESS  OF  SOFTWARE 
DEVELOPMENT  ORGANIZATIONS  BY  GROUP 


GROUP 

RATING 

NUMBER 
OF 

COMPANIES 

1 

ABOVE  AVERAGE 

6 

li 

AVERAGE 

6 

III 

BELOW  AVERAGE 

7 

IV 

WELL  BELOW 
AVERAGE 

2 
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Data  gathered  on  the  number  of  analysts  and  programmers  employed  indicated 
that: 

Most  companies  did  not  differentiate  between  the  two  job  classifi- 
cations. 

Group  I  companies  provided  more  detail  than  the  other  companies. 

b.  Interdepartmental  Relationships 

The  surveyed  software  departments  were  asked  to  rate  the  quantity  and 
effectiveness  of  their  communications  with  other  departments. 

The  most  effective  communications  were  between  software  maintenance  and 
hardware  development  departments. 

The  most  important  interfaces  were  with: 

Product  planning. 

Market  planning. 

Business  planning. 

The  overall  communications  of  the  different  groups  were  rated  at  about  the 
same  level  for  each  group. 

c.  Organizational  Changes 

Most  of  the  companies  surveyed  were  growing  rapidly,  and  growth  was  the 
principal  force  causing  organizational  changes. 

The  changes  were  usually  towards  more  functional  specialization  or  into  new 
lines  of  business  divisions. 
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3.  COST  AND  FINANCIAL  RATIOS 

•  Very  little  meaningful  data  were  provided  by  the  surveyed  companies  on 
software  development  cost. 

•  Software  development  was  found  to  cost  twice  as  much  as  hardware 
development. 

•  Maintenance  is  about  60%  of  the  software  budget. 

•  Most  respondents  had  difficulty  distinguishing  between  sustenance  and 
enhancement  of  software. 

•  The  most  effective  organizations  had  the  best  understanding  of  their  costs. 

4.  PROGRAMMING  STANDARDS 

•  Eighty-one  percent  of  all  the  companies  reported  that  they  employed  program- 
ming standards. 

•  There  may  not  be  a  direct  correlation  between  the  use  of  programming 
standards  and  the  effectiveness  of  software  development. 

•  Those  companies  that  gave  themselves  high  ratings  for  effectiveness  and  level 
of  adherence  to  programming  standards  were  among  the  lower-rated 
companies  in  effective  software  development. 

5.  QUALITY  CONTROL 

•  The  level  of  quality  control  employed  by  each  company  in  the  software 
development  process  was  evaluated. 

A  high  level  of  quality  control  was  associated  with  the  Group  I 
companies. 
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A  much  lower  level  was  found  in  the  lower-rated  groups. 

The  nnost  effective  software  development  departments  employed  quality 
control  techniques  that  were: 

Quantitative. 

Scientific. 

Statistical. 

Historical. 

Predictive. 

The  surveyed  companies  frequently  mentioned  that  they  could  improve  their 
software  product  quality  by  improving  the  product  specifications  or  the 
specification  process. 

Improved  quality  assurance  was  also  mentioned  frequently. 

MEASURES  OF  SOFTWARE  DEVELOPMENT  SUCCESS 

The  companies  indicated  that  they  most  often  employed  the  following 
measures  of  software  development  successes  and  failures: 

The  product  was  developed  on  schedule. 

Customers  have  accepted  the  product. 

The  product  works. 

The  product  was  developed  on  budget. 
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The  most  frequently  cited  reasons  for  software  development  success  were: 

Well-conceived  and  complete  specifications. 

A  thorough  and  well-designed  product. 

Good  controls. 
Reasons  for  software  development  failure  included: 

Being  out  of  touch  with  the  marketplace. 

Specifications  that  were: 
Poor. 

Impossible. 
Changing. 
Inadequate  reviews  and  signoffs. 
FUTURE  OF  SOFTWARE  DEVELOPMENT 

Respondent  companies  expect  that  the  following  software  development  m 
odologies  will  be  available  by  1985: 

More  programming  tools. 

Automatic  program  generators. 

Built-in  standards. 

Higher-level  language. 


Computerized  documentation. 


B.  RECOMMENDATIONS 

I.        ORGANIZING  FOR  EFFECTIVE  SOFTWARE  DEVELOPMENT 
a.        Reporting  Structure 

•  Software  development  managers  should  report  to  the  director  of  research  and 
development.  They  should  not  report  to  division  heads  or  marketing  managers. 

•  A  project-oriented  organization  is  most  highly  recommended. 

•  Matrix  organizations  can  be  very  effective  under  excellent  management  but 
they  are  riskier  than  project  organizations  because  a  change  in  management  or 
management  objectives  can  very  severely  impair  their  ability  to  perform 
productively. 

•  Business  unit  organizations  have  the  same  weakness  as  the  matrix  organiza- 
tions, but  a  number  of  companies  have  successfully  implemented  this 
option  and  it  should  be  given  thorough  consideration. 

•  Functional  organizations  appear  to  be  safest  because  they  are  rarely  very  good 
or  very  bad,  but  they  usually  yield  the  most  mediocre  software  development 
results. 

•  The  use  of  advanced  development  departments  in  major  product  lines  should  be 
encouraged  because  they  provide: 

Alternate  non-management  career  paths  for  software  developers. 
.   -         A  foundation  for  new  divisions. 
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Non-management  career  paths  providing  for  high-level  advancement  of 
software  personnel  should  be  implemented. 

Advancing  software  personnel  to  high-level  management  consultant 
positions  within  the  research  and  development  organizations  is  likely  to 
improve  the  software  development  process. 

INPUT  recommends  that  the  maintenance  function  be  separated  from  the 
development  function. 

Development  organizations  should  be  organized  so  that  software  and  hardware 
development  engineers  work  as  closely  together  as  possible. 

b.        Interdepartmental  Relationships 

Provide  for  good  communications  between  the  software  development 
department  and  both  in  software  maintenance  and  hardware  development 
groups. 

The  most  important  interfaces  with  software  development  include: 
Product  planning. 
Market  planning. 
Business  planning. 

The  most  vital  interface  for  effective  software  development  is  with  the  end 
user  of  the  product. 

Communications  between  software  development  personnel  and  the  end 
user  should  be  encouraged  in  every  way  possible. 

Combining  a  close  interface  with  the  customer  and  planning  process  is 
very  important  to  the  success  of  development. 
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To  improve  productivity  and  effectiveness  in  developing  high-quality 
software,  management  should: 

Impart  a  "sense  of  mission"  (i.e.,  company  mission  and  goals)  to  the 
developers. 

Convey  how  important  software  development  effort  is  to  that  mission. 

Increase  awareness  of  how  important  product  development  efforts  are 
to  sales  and  revenues  -  for  the  company  and  the  product. 

c.        Organizational  Changes 

As  development  efforts  grow,  a  quality  assurance  department  should  be 
established  that  reports  to  the  director  of  research  and  development  and  is 
separate  from  software  and  hardware  engineering. 

Large  organizations  should  also  employ  advanced  development  teams. 

Large  software  development  departments  should  have  their  own  documen- 
tation and  publications  people. 

As  the  software  organization  grows,  formal  planning  functions  should  be 
established  in  the  group  that  include  personnel  from: 

Marketing. 

Software  engineering. 
Hardware  engineering. 
Business  planning. 
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•  Selective  rotation  of  personnel  from  applications  to  systems  development 
should  be  considered. 

•  Rotating  personnel  from  development  to  maintenance  is  not  recommended 
because  the  skills,  talents,  and  personality  traits  required  for  each  function 
are  different. 

2.  COST  AND  FINANCIAL  RATIOS 

•  Strong  management,  financial  and  productivity  measures  and  controls  must  be 
employed  to  attain  effective  software  development. 

3.  PROGRAMMING  STANDARDS 

•  A  study  of  how  standards  affect  software  productivity  in  the  organization 
should  be  given  consideration  because  there  are  indications  that  the  type  of 
programming  standards  employed  by  a  company  may  be  counter-productive  to 
effective  software  development. 

4.  QUALITY  CONTROL 

•  A  high-level  of  quality  control  is  extremely  important  to  effective  software 
development. 

•  Quality  control  should  be  measured  and  related  to  revenues  and  profits. 

•  Goals,  not  just  measurements,  should  be  established  for  quality  control. 

•  ■      Control  of  the  specification  process  is  particularly  important. 

5.  MEASURES  OF  SOFTWARE  DEVELOPMENT  SUCCESS 

•  Surprisingly,  very  few  companies  measured  the  success  of  their  software 
products  development  by  its  return  on  investment,  yet  this  was  the  most 
important  measurement  employed. 
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In  addition,  success  should  be  measured  by: 

Increased  sales. 

Number  of  installations. 

Number  of  customer  complaints. 

Management  should  motivate  software  development  personnel  by  clearly 
defining  how  the  success  of  their  efforts  and  products  are  measured  and 
periodically  reviewing  their  achievements  with  them. 

The  single  most  important  reason  for  software  development  success  is  having 
good,  close  relations  between  end  users  and  development  personnel. 

Other  important  factors  in  software  development  success  include  having  good 
controls,  measures,  reviews  and  sign-offs  at  all  stages  of  development. 

FUTURE  OF  SOFTWARE  DEVELOPMENT 

INPUT  recommends: 

Converting  to  languages  such  as  PASCAL  and  "C." 

Incorporating  more  software  into  hardware. 

Creating  mechanized  program  generators. 
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Ill       ANALYSIS  OF  SOFTWARE  DEVELOPMENT  EFFORT 


A.       EVALUATION  TECHNIQUE 

•  An  analysis  of  the  data  gathered  in  the  interviews  did  not  yield  any  single 
measurement  for  the  overall  effectiveness  of  the  software  development 
effort. 

•  Special  attention  was  given  to: 

Lines  of  code  produced  per  person  month. 
Cost  per  line  of  code. 

•  Neither  measure  was  found  to  be  useful  in  evaluating  the  software  develop- 
ment effort,  for  the  following  reasons: 

Only  I  I  of  the  21  companies  provided  sufficient  data  to  derive  these 
figures. 

The  code  was  developed  in  a  variety  of  languages. 

There  were  no  means  of  evaluating  the  quality  of  the  code  produced. 

The  figures  given  in  most  cases  were  rough  estimates. 
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The  cost  per  line  of  code  was  effected  by  pay  scales  that  differed 
substantially  for  companies  located  in  different  parts  of  the  country. 


The  cost  per  line  varied  fronn  $0.17  to  $14.67,  due  to  a  lack  of  standard 
definitions  of  the  variables  involved. 

One  of  the  companies  reported  that  it  produced  16,666  lines  of  code  per 
person  month,  which  was  improbable,  if  not  impossible. 

The  research  staff  concluded  that  the  only  useful  measurement  of  overall 
effectiveness  would  have  to  be  subjective. 

The  two  interviewers  were  asked  to  rate  each  of  the  companies  they 
interviewed  (on  a  scale  of  1  to  4,  where  I  was  the  highest  rating  and  4  was  the 
lowest)  based  on  their  judgement  of  the  overall  effectiveness  of  the  software 
development  organization.  Specific  factors  to  be  assessed  included: 

The  productivity  of  the  organization. 

The  market  success  and  acceptance  of  the  product. 

The  profitability  of  the  product. 

The  quality  and  reliability  of  the  product. 

And  the  cost  and  level  of  maintenance  required  for  the  product. 

Each  interviewer  then  reviewed  the  ratings  given  by  the  other,  and  the 
ratings  were  found  to  be  consistent. 

Exhibit  111- I  shows  that  the  ratings  were  fairly  evenly  distributed  between  the 
first  three  categories  and  between  on-site  and  telephone  interviews.  Category 
IV  was  exceptional  in  that  only  2  companies  received  that  rating  and  both  were 
telephone  interviews. 
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OVERALL  EFFECTIVENESS  RATINGS  OF 
SOFTWARE  DEVELOPMENT  GROUPS 


NUMBER  OF  COMPANIES 

RATED 

RATING 

ON-SITE 
INTERVIEWS 

TELEPHONE 
INTERVIEWS 

TOTAL 
INTERVIEWS 

1 

3 

3 

6 

I! 

2 

4 

6 

ill 

3 

4 

7 

IV 

0 

2 

2 

TOTAL 

8 

13 

21 

Some  of  the  Exhibits  do  not  include  data  on  Group  IV  because  insufficient  data 
were  obtained  from  them. 

These  ratings  can  be  interpreted  as  follows: 

I  Above  average. 

II  Average. 

III  Below  average. 

IV  Well  below  average. 

METHODOLOGY  OF  TESTING  RATINGS 

•  Since  the  ratings  were  in  large  part  the  subjective  judgements  of  the 
consultant,  several  other  tests  were  applied  to  the  ratings  to  validate  the 
methodology  as  well  as  the  ratings  themselves. 

•  All  of  the  interview  questionnaires  were  reviewed  in  detail  for  inconsistencies 
within  each  group. 

A  number  of  inconsistencies  were  found,  but  they  were  generally 
justifiable. 

For  example,  several  widely  respected  and  very  successful  companies 
were  given  ratings  of  111. 

One  received  this  rating  because  the  success  of  the  firm  was  not 
related  at  all  to  the  effectiveness  of  the  software  development 
group  interviewed. 


B. 
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Another  received  this  rating  because  there  had  been  some  major 
management  changes  in  the  past  year  that  had  had  detrimental 
effects  on  the  software  development  group. 

A  number  of  apparent  inconsistencies  will  be  discussed  later  in  the  text 
of  this  report. 

The  companies  and  their  ratings  were  reviewed  by  several  of  INPUT'S  senior 
consultants  who  have  extensive  experience  in  the  computer  industry  and  a  high 
level  of  knowledge  of  the  companies  interviewed. 

The  consultants  generally  agreed  with  the  ratings. 

in  the  few  cases  where  the  consultants  did  not  agree  with  the  ratings, 
they  were  unaware  of  extenuating  circumstances  such  as  those  given 
above. 

A  third  test  was  applied  to  the  ratings  based  entirely  on  verifiable  empirical 
data. 

This  test  was  based  on  the  hypothesis  that  there  should  be  some 
correlation  between  the  overall  success  of  the  corporation  and  the 
effectiveness  of  its  software  development  group. 

The  success  of  the  corporation  would  be  gauged  by  several  widely 
accepted  measurements: 

Average  annual  growth  rate  in  revenues  for  the  past  four  years. 

Average  annual  growth  rate  in  profits  for  the  past  four  years. 

Pretax  profit  margins. 


-  21  - 


INPUT 


Expenditures  on  research  and  development  as  a  percent  of 
revenues. 

Productivity  as  measured  by  revenue  per  employee. 

In  order  to  qualify  for  this  test,  individual  companies  had  to  meet  the 
following  criteria: 

They  had  to  be  public  companies. 

Computer  manufacturing  had  to  be  a  significant,  if  not  pre- 
dominant, part  of  their  business. 

Of  the  six  companies  rated  1,  five  of  them  met  this  criteria. 

Of  the  remaining  15  companies  in  the  three  lower-rated  groups,  five 
met  these  criteria.  They  included: 

One  Il-rated  company. 

Three  Ill-rated  companies. 

One  IV-rated  company. 

One  of  the  companies  had  recently  been  acquired. 

Data  from  1974-1978  were  used  for  this  company,  rather  than 

data  from  1975-1979  as  for  the  other  companies. 

The  data  were  judged  to  be  consistent  with  the  company's 
current  performance  and  comparable  to  the  data  for  other 
companies. 
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One  of  the  companies  had  an  extremely  volatile  earnings  record. 
Consequently,  growth  rates  for  a  shorter  period  than  1975-1979  were 
used  in  the  analysis,  as  they  appeared  to  be  a  more  accurate  reflection 
of  the  company's  performance. 

The  revenue,  profit,  and  research  and  development  expenditures  for  the  two 
sets  of  companies  are  shown  in  Exhibit  II 1-2.  The  combined  results  were 
calculated  in  two  ways: 

The  "average  percentage"  numbers  were  derived  by  averaging  the 
individual  percentages  of  each  company  in  the  set. 

The  "total  percentage"  numbers  were  derived  by  totaling  the  revenues 
of  the  individual  companies  in  the  set  and  calculating  percentages  based 
on  total  revenues.  ^ 

The  use  of  both  techniques  yielded  essentially  the  same  results. 

The  public  companies  in  group  I  clearly  out-performed  the  public  companies 
from  groups  II,  III  and  IV  in  the  revenue  and  profit  performance  measures. 

The  highly  rated  companies  also  expended  a  substantially  larger  percent  of 
their  revenues  on  research  and  development  than  did  the  lower-rated 
companies. 

The  sharpest  distinction  between  the  two  sets  of  companies  is  seen  in  the 
pretax  profit  average  annual  growth  rates. 

Comparable  information  for  each  of  the  five  companies  in  both  sets  is  shown 
in  Exhibits  III-3  and  III-4. 

Company  C's  193%  growth  rate  in  pretax  profits  is  due  in  part  to  very 
aggressive  acquisition  activity. 
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EXHIBIT  III-2 

REVENUE,  PROFIT,  AND  RESEARCH  AND  DEVELOPMENT 
DATA  ON  PUBLIC  COMPANIES  IN  GROUP  I  COMPARED  TO 
PUBLIC  COMPANIES  IN  GROUPS  II,  III  AND  IV 
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EXHIBIT  III-3 


INDIVIDUAL  PERFORMANCES  OF  PUBLIC  COMPANIES 

FROM  GROUP  I 
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EXHIBIT 


INDIVIDUAL  PERFORMANCE  OF  PUBLIC 
COMPANIES  FROM  GROUPS  II,  III  AND  IV 
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Company  K  shows  characteristics  more  compatible  with  the  Group  1 
companies  than  with  its  peers. 

This  company  received  a  ill  rating  -  even  though  it  has  high 
standards  and  produces  quality  products  -  because  evidence  of 
formal  controls  and  procedures  was  not  apparent. 

More  importantly,  a  major  new  product  was  apparently  being 
developed  in  a  vacuum. 

There  was  very  little  contact  between  sales  and  customers,  and 
very  little  concern  for  sales  and  profits,  even  by  the  division 
manager. 

After  the  ratings  were  assigned,  the  company  announced  a 
substantial  drop  in  profits  due  to  unexpectedly  high  research  and 
development  expenses  for  the  new  product. 

Management  has  had  little  previous  experience  with  products  of 
this  type. 

•  The  sixth  company  in  Group  I,  the  privately  held  company  F,  is  known  to  have 
one  of  the  most  incredible  revenue  growth  rates  in  the  history  of  the  computer 
industry. 

It  is  believed  to  share  the  same  financial  characteristics  as  the  other 
companies. 

Although  the  company  is  substantially  smaller  than  the  other  Group  I 
companies,  it  is  known  for  obtaining  outstanding  senior  managers  from 
other  companies. 

The  company's  director  of  software  was  responsible  for  developing  the 
premier  computer  system  of  one  of  the  other  Group  I  companies. 
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There  is  a  substantial  difference  in  size  between  the  two  sets  of  public 
companies. 

Four  Group  I  public  connpanies  have  revenues  over  $1  billion,  and  the 
fifth  has  $200  nniilion. 

Groups  II,  III  and  IV  public  companies  include  one  $1  billion-plus 
company,  one  $0.5  billion  company  and  three  companies  with  less  than 
$200  million  in  revenues. 

Generally,  smaller  companies  are  able  to  show  greater  percent  growth  rates 
than  larger  companies  because  the  calculation  is  performed  from  a  smaller 
base. 

However,  in  this  sample  of  public  companies,  the  larger  Group  I  far  out- 
performed the  smaller  ones  in  Groups  11,  111  and  IV. 

This  unexpected  phenomenon  reinforces  the  qualitative  differences 
between  the  two  sets  of  companies. 

Exhibit  I1I-5  shows  productivity  as  measured  by  revenue  per  employee  for  the 
respondent  public  companies. 

Productivity  was  14%  higher  among  Group  1  companies  than  it  was 
among  Groups  II,  111  and  IV  companies. 

A  fourth  test  of  the  ratings  was  employed  based  on  users'  ratings  of  software 
in  a  survey  conducted  by  Datapro,  a  publisher  of  information  about  software. 

Five  of  the  six  vendors  in  Group  1  received  ratings  of  E  or  Et,  the  two  highest 
ratings  given  on  a  five-point  scale. 

The  sixth  vendor's  software  was  not  rated,  but  the  manager  of  that 
company's  software  division  was  responsible,  while  employed  at  another 
firm,  for  the  development  of  one  of  the  systems  rated  Et. 
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WEIGHTED  AVERAGE  PRODUCTIVITY 
OF  RESPONDENT  PUBLIC  COMPANIES 
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One  of  the  vendor's  software  products  was  also  on  Datapro's  honor  roll. 

•  None  of  the  15  companies  in  Groups  II,  III  and  IV  offered  software  that  was 
rated  by  Datapro's  users. 

The  lack  of  a  Datapro  rating  does  not  necessarily  indicate  poor-quality 
software. 

Most  of  the  software  rated  by  Datapro  is  applications  software, 
whereas  much  of  the  software  the  interviewees  developed  was  systems 
software. 

Many  of  the  Groups  II,  111  and  IV  companies  did  offer  applications 
software  but  did  not  receive  a  rating.  This  implies  that  the  software  is 
either  not  widely  used  or  not  considered  high  quality. 

It  was  surprising  that  none  of  the  Groups  II,  111  and  IV  companies' 
software  was  even  rated. 

•  The  conclusion  drawn  from  this  analysis  of  Datapro's  user  ratings  is  that  it 
confirms  INPUT'S  rating  of  the  Group  I  companies  and  does  not  refute  INPUT'S 
rating  of  the  Group  II,  111  and  IV  companies. 

C       CATEGORIZATION  OF  COMPANIES  INTERVIEWED 

•  Characteristics  of  the  four  groups  of  companies  interviewed  in  terms  of 
revenues  and  employees  are  shown  in  Exhibit  \\\-6. 

The  Group  I  company  averages  were  substantially  inflated  by  one 
company  with  over  $10  billion  in  revenues. 


-  30- 


INPl 


o 
o 


in 


o 


CL 
D 
O 

u 
> 

CQ 

(/) 
LU 
LU 

>■ 

o 


LU 

Q 

Z 
< 

I  LU 
—  D 
"-  Z 

t  ^ 

CD  LU 

lu  a: 
o 


LU 

> 

o 

z 
o 

I- 

< 

o 
o 

LU 

< 

u 


c/) 

LU 
UJ 

>- 

O 
_l 

Q. 

LU 


Z 

o 


C/) 
LU 

D 
Z 
LU 

> 
LU 


LU 
CQ 

Z 


LU 
U 
< 

LU 
> 
< 


< 

H 
O 
H 


O 


LL 
O 


LU 
U 
< 

a: 

LU 

> 
< 


< 

O 


< 

o 
u 


o 
o 
o 


o 
o 
o 

o 


o 
o 
o 

in 


o 
o 
o 

(N 


o 
o 
o 


o 

o 

in 

in 

r— 

(X) 

CO 

CO 

O 

s 

o 

ro 

in 

T— 

in 

o 

CO 

(N 

id" 

cr> 

tN 

CO 

in 

cn 

o 

CO 

=r 

tN 

o 

CO 

o 

cn 

=1- 

in 


o 


O 


O 

</>- 


tN 

CD 
tN 


to 
m 


V£5 


O 
O 
O 

in 


o 
in 

tN 


CO 

cn 


cn 


in 
cn 


CO 


CO 
CO 


cn 
o 
to 

in 


tN 

to 


CO 

cn 


in 
cn 

CO 
CN 


(X) 


CN  t— 
fN 


Q. 

O 

o 


_i 
< 


-31  - 


INPUT 


with  the  above  exceptions,  the  companies  in  Groups  1  and  11  are  fairly 
comparable. 


The  companies  in  Groups  ill  and  IV  are  substantially  smaller  than  the 
companies  in  Groups  I  and  II. 

Company  size  seems  to  be  a  factor  in  that  organizational  effectiveness 
in  developing  software  is  primarily  a  product  of  management's 
experience  and  sophistication. 

Good  management  is  definitely  important  to  good  software  develop- 
ment, and  the  larger  companies  generally  had  more  of  it. 

The  organizations  were  categorized  by  themselves  and  INPUT  by  type  of 
company,  type  of  software,  type  of  software  development,  group  type  and 
complete  size  orientation,  as  shown  in  Exhibit  III-7. 

The  vendors'  categorizations  exceed  100%  in  all  categories  because 
many  of  the  vendors  fit  into  multiple  categories. 

INPUT'S  categorizations  were  based  on  the  primary  or  principal 
category  and  allowed  only  one  category  per  company. 

Almost  all  of  the  companies  were  hardware  manufacturers  that  developed 
systems  software. 

Four  of  the  organizations  developed  communications  software  for  the 
computer  switching  systems  they  manufactured.  Five  organizations  also 
developed  applications  software. 

All  of  the  companies  in  Group  I  were  hardware  computer  manufacturers. 
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EXHIBIT  III-7 
CATEGORIZATION  OF  VENDORS 
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The  tighter  and  higher  quality  control  measures  generally  employed  by 
the  companies  in  Group  I  are  believed  to  be  related  to  those  employed 
in  the  manufacturing  process. 

Several  of  the  companies  in  Group  I  stated  that  they  tried  to  use  the 
same  procedures  in  software  development  as  they  did  in  hardware 
development. 

Organizations  that  indicated  "maintenance  only"  meant  that  they  also  main- 
tained software  in  addition  to  developing  it. 

Almost  75%  of  the  organizations  produced  computers  in  the  small  to  medium 
size  range. 

It  should  be  noted  that  none  of  the  Group  I  companies  was  new. 
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IV   ORGANIZING   FOR   SOFTWARE  DEVELOPMENT 


IV 


A. 


ORGANIZING  FOR  SOFTWARE  DEVELOPMENT 

TYPICAL  REPORTING  STRUCTURES  OF  COMPANIES  SURVEYED 


•  In  all  organizations,  the  manager  of  software  development  reported  to  high- 
level  management,  as  shown  in  Exhibit  IV- i. 

The  software  manager  reported  to  top-level  management  (the  president 
or  general  manager  of  a  division)  in  25%  of  the  organizations,  and  to  a 
second-level  manager  in  over  75%  (eleven  to  the  director  of  research 
and  development  and  four  to  the  vice  president  of  marketing). 

Those  software  managers  that  reported  to  top-level  management  were 
generally  from  smaller  organizations. 

Eighty  percent  of  the  cases  where  software  reported  to  marketing  were 
in  Groups  II  and  ill,  which  indicates  that  reporting  to  marketing  may  not 
contribute  to  the  effectiveness  of  the  software  development  group. 

•  Reporting  directly  to  top  management  also  does  not  appear  to  be  very 
beneficial  to  the  software  development  department  because  the  former 
probably  does  not  have  the  time  to  be  involved  in  the  level  of  detail  required 
to  supervise  the  software  group. 
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All  software  development  organizations  surveyed  were  divided  into  three 
different  types: 

The  Functional  Type  is  organized  so  that  individuals  are  assigned  to 
specific  functions  that  cross  product  lines. 

The  Project  Type  is  organized  so  that  individuals  are  assigned  to 
specific  products  and  may  perform  a  variety  of  functions  related  to 
that  product. 

The  Matrix  Type  is  organized  so  that  individuals  share  responsibility 
and/or  authority  for  developing  the  software  with  other  individuals 
outside  of  the  software  development  organization. 

One  company  that  did  not  fit  into  these  three  categories  had  an 
organization  based  on  the  Business  Unit. 

The  Business  Unit  contains  all  of  the  functions,  or  represen- 
tatives of  the  functions,  necessary  to  produce  and  market  a 
product  (including  manufacturing,  marketing,  planning  and 
quality  assurance)  assigned  to  a  development  group. 

The  business  unit  is  supposed  to  have  all  of  the  capabilities  of  a 
company. 

This  company  was  categorized  as  a  project  organization  for  the 
purposes  of  this  study. 

The  distribution  of  groups  by  organization  was  analyzed  as  shown  in  Exhibit  IV- 
2. 

The  majority  of  companies  were  organized  by  project. 
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The  balance  of  companies  were  evenly  divided  between  functional  and 
matrix  organization  types. 

Group  I  companies  had  a  larger  percentage  (67%)  of  project  organizations  than 
did  the  other  groups,  as  shown  in  Exhibit  iV-3. 

None  of  the  Group  I  companies  had  a  functional  organization. 

One-third  of  the  Group  I  companies  had  a  matrix  organization. 

INPUT  believes  that  project  organization  contributes  more  to  the  success  and 
effectiveness  of  the  software  development  effort  for  the  following  reasons: 

Software  development  people  have  a  greater  sense  of  identification 
with  the  product  in  this  form  of  organization,  which  is  a  very  important 
factor  in  the  effective  development  of  software. 

This  type  of  organization  is  most  effective  in  imparting  a  sense  of 
"mission"  or  purpose  which  is  important  to  the  development  of  good 
software. 

Project  management  also  requires  smaller  groups  of  people,  which 
appear  to  be  more  effective  in  development  than  larger  groups. 

Responsibility  and  authority  for  the  project  are  clearly  defined  and 
understood. 

Frequent  and  good  communication  with  the  end  user  are  very  important 
to  the  software  organization,  and  project  management  facilitates  this 
more  than  the  other  types. 

The  project  organizations'  comments  on  their  own  strengths  and  weaknesses 
appear  in  Exhibit  IV-4. 
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EXHIBIT  IV-U 

ORGANIZATIONAL  STRENGTHS  AND  WEAKNESSES  SELF-ASSESSED  BY 

PROJECT  ORGANIZATIONS 


GROUP  1 

STRENGTHS 

WEAKNESSES 

A 

"Product  identification  is  an  ego 

motivator. " 
"Good  communications." 
"Manufacturing  flexibility  enables 

us  to  meet  changing  business 

needs. " 

"If  strategy  is  not  clearly  defined, 

problems  will  arise." 
"Failure  in  objective  setting. 

process  can  cause  changes  in 

priorities." 

B 

"Care  for  the  individual." 
"People  are  given  freedom." 
"Good  communications  with  the 
field  organization." 

"Lack  of  procedures." 

c 

"Small  teams,  two  to  four  people." 
"We  don't  use  'chief  programmer,' 

we  have  a  project  leader  and 

everyone  contributes." 
"We  separate  the  development  and 

sustaining  functions,  but  rotate 

everyone  from  function  to 

function. " 

"Too  many  critical  people." 

"Seoarate  custom  Droarammina 
group  causes  communications 
and  cooperation  problems." 

E 

"Our  management  approach  has 
been  to  copy  our  hardware 
business  in  our  software 
business. " 

"Cost  accountability." 

"Inexperienced  staff." 

GROUP  II 

G 

"The  small  size  of  our  department 
increases  productivity  and 
improves  communications." 

"We  will  require  a  more  complex 
organizational  structure  if 
if  we  expand .  " 

N 

"Ability  to  be  responsive  to  the 
needs  of  our  dealers  and  their 
customers . " 

P 

"Our  chain  of  command  is  good  and 
well  defined.  " 

"Everyone  has  a  strong  sense  of 
responsibility  to  each  product,  in- 
cluding testing  and  documentation." 

"Limited  growth  for  individuals, 
chances  of  becoming  an  analyst 
are  not  very  good." 

"Sometimes  too  much  concentration 
of  knowledge  in  one  person." 
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EXHIBIT  IV-U  (CONT.) 
ORGANIZATIONAL  STRENGTHS  AND  WEAKNESSES  SELF-ASSESSED  BY 

PROJECT  ORGANIZATIONS 


GROUP  III 

STRENGTHS 

WEAKNESSES 

1 

"Separation  of  functions  test 
and  maintenance  from  the 
development  group." 

"Designated  systems  designers." 

"Planned  migration  through  or- 
ganization for  new  college  hires." 

"Programmers  identify  so  strongly 
with  their  product  line  that 
they  resist  moving  to  another 
product.  " 

"Planned  migration  also  causes 
problems. " 

K 

"Specialized  products  require 
Tunciionai  uivisions  which 
provide  strength  of  highly 
specialized  people." 

"We  have  problems  with  system 
integration. " 

Q 

"Each  individual  in  unit  gets  good 
overall  view  of  products." 

"Diverse  activities  v/ithin  unit 
provide  challenging  environment." 

"Excellent  feedback  from  all 
operations  produces  pride  of 
ownership  and  high  motivation." 

"Duplication  of  effort  between 
units." 

"Very  difficult  to  get  help  from 
other  units." 

S 

None  reported 

None  reported 

GROUP  IV 

J 

"Informal  organization." 

"Organization  is  collapsing,  we 
lost  80%  of  our  software 
group  in  past  two  years." 

U 

"Good  communications." 

"Not  enough  depth  in  people 
due  to  small  size.  " 
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Functional  organizations  appear  to  be  associated  mostly  with  mediocre 
development  efforts. 

None  of  the  top-rated  or  bottom-rated  companies  had  this  form  of 
organization. 

Functional  organizations  lack  most  of  the  benefits  attributed  above  to 
project  organizations. 

Functional  organizations  do  provide  several  benefits  towards  software  devel- 
opment. 

They  allow  for  more  specialized  skills  that  can  be  employed  more 
efficiently. 

They  are  safer  in  that  fewer  individuals  become  critical  of  a  specific 
project. 

They  provide  a  more  flexible  environment  for  changes  in  assignments 
and  priorities. 

The  functional  organizations'  comments  on  their  organizational  strengths  and 
weaknesses  appear  in  Exhibit  IV-5. 

Matrix  organizations  were  developed  to  take  advantage  of  all  of  the  benefits 
of  both  project  and  functional  organizations.  This  survey  found  that  they  work 
better  in  theory  than  in  practice.  Because  of  the  complexity  of  this  type  of 
organization,  more  things  generally  go  wrong  than  go  right. 

Two  of  the  Group  I  companies  had  a  form  of  matrix  management  in  their 
software  development  groups.  In  one  the  matrix  was  relatively  simple: 

Overall  responsibility  for  the  project  was  assigned  to  product  managers. 
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EXHIBIT  IV-5 

ORGANIZATIONAL  STRENGTHS  AND  WEAKNESSES  SELF-ASSESSED  BY 

FUNCTIONAL  ORGANIZATIONS 


GROUP  II 

STRENGTHS 

WEAKNESSES 

M 

"Specialized  skills  oriented 
towards  tasks." 

"No  systems  development  in 
marketing. " 

0 

"Separate  support  group  which 
deals  directly  with  dealers." 

"No  distinct  research  and  develop- 
ment group.  Research  and 
development  is  performed  by 
software  development  and 
manufacturing  engineering,  which 
are  separate  groups." 

GROUP  III 

R 

"Each  group  does  its  own  main- 
tenance and  development." 

"Chief  programmers  who  have 
lots  of  responsibility  including 
product  specialization." 

T 

None  reported 

"People  are  not  assigned  to  a 
particular  project." 
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The  mission  was  clear. 

Ample  resources  were  available  to  do  the  job. 

The  other  Group  I  matrix  organization,  just  emerging  out  of  a  project 
organization,  was  already  developing  problems: 

The  successful  coordination  of  forces  in  the  matrix  were  in  the  hands  of 
a  very  high-level  manager  who  appeared  to  be  losing  his  grip  due  to  the 
size  and  growth  of  the  organization. 

Conflicts  were  increasing  between  various  managers  that  required 
frequent  high-level  management  intervention. 

Priorities  were  being  disrupted  or  altered  by  marketing  or  development 
managers.  The  matrix  organizations'  comments  on  their  organizational 
strengths  and  weaknesses  appear  in  Exhibit  IV-6. 

The  business  unit  type  of  organization  offers  several  advantages. 

It  is  very  close  to  a  project  type  organization,  especially  in  respect  to 
identification  with  the  product  and  communications  with  the  end  user. 

The  business  unit  manager  has  a  great  deal  of  authority  along  with  full 
responsibility  for  the  success  of  the  product. 

It  does  not  require  superb  management  and  is  not  as  subject  to  political 
forces  as  matrix  management. 

The  business  unit  company  in  this  survey  was  rated  in  Group  III  due  to  very 
serious  conflicts  among  the  highest  levels  of  management  (resulting  in  some 
senior  managers  leaving  the  company),  which  disrupted  the  business  unit's 
sense  of  mission  and  goals. 
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EXHIBIT  IV-6 

ORGANIZATIONAL  STRENGTHS  AND  WEAKNESSES  SELF-ASSESSED  BY 

MATRIX  ORGANIZATIONS 


GROUP  1 

STRENGTHS 

WEAKNESSES 

B 

"Each  software  group  has  its  own 
quality  assurance  and  publi- 
cations group." 

"Great  deal  of  pride  and  motiva- 
tion to  produce  good  products." 

"Standard  development  procedures 
produce  high-quality  software." 

"Very  large  organization  tends  to 

lack  control." 
"Lack  of  written  communications 

causes  losses  in  development 

time. " 

F 

"1  coordinate  the  development 

activities  well." 
"Software  development  is  a  profit 

and  loss  center." 
cacn  group  win  nave  its  own 

engineering  and  publication 

group  as  we  grow." 

"Conflicts  between  marketing  and 
development  product  managers." 

GROUP  II 

L 

"Fully  exploits  specialized  skills." 
"Provides  uniform  performance 

with  no  extreme  failures  or 

successes." 

"No  one  person  is  responsible  or 

accountable  for  a  specific 

product." 
"People  feel  no  identification  with, 

or  ownership  of,  product." 
"Decisions  must  be  made  through 

negotiations. 

GROUP  III 

H 

"Broad  range  of  technical  chal- 

personnel  and  attract  new 
hires. " 

"In-depth  industry  and  applica- 
tion expertise." 



"Changes  in  priorities  consume 
great  deal  of  management  time." 

"Many  decisions  must  be  made  at 
high  level  in  organization." 
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The  company's  past  record  in  software  and  hardware  development  is  one 
of  the  best  in  the  industry. 

it  is  a  tribute  to  the  business  unit  organization  that  everything  hadn't 
fallen  apart  under  the  conditions  this  company  experienced. 

A  closer  look  at  more  organizations  using  the  business  unit  concept  would 
probably  yield  some  very  useful  information. 

Many  of  the  organizations,  regardless  of  organization  type,  had  a  separate 
development  department  dedicated  to  advanced  systems  development. 

This  group  was  project-oriented. 

It  usually  consisted  of  hardware  as  well  as  software  engineers. 

The  Advanced  Development  Department  was  used  in  several  ways  by  the 
company's  survey: 

When  the  product  development  was  completed,  the  nucleus  of  people  in 
the  department  could  be  promoted  to  section  heads  in  a  new  division 
which  would  continue  development  for  the  product  through  its  life 
cycle. 

In  other  companies,  the  department  would  then  move  on  to  developing 
the  next  future  product  as  each  one  was  completed. 

It  provided  an  alternative  high  level  carreer  path  for  the  individual. 

A  number  of  companies  provided  career  advancement  of  up  to  five  levels 
without  imposing  management  responsibility  on  key  creative  software 
personnel. 


-47- 


INPUT 


In  one  Group  I  company,  the  head  of  the  department  stated  that  he  had 
a  number  of  people  working  for  him  who  were  higher  payed  than  he  was. 

Some  companies  had  positions  known  as  "consultants"  who  reported  to  the  top 
management  in  the  software  organizations. 

These  individuals  were  often  considered  geniuses  or  wizards. 

They  usually  had  no  specific  standing  assignments. 

They  were  often  employed  to  keep  the  head  of  software  in  touch  with 
the  most  advanced  technology. 

The  position  offered  another  career  path  for  the  nonmanagement- 
oriented  software  engineer. 

There  was  a  striking  difference  between  the  Group  I  companies  and  all  the 
other  groups  on  the  issue  of  separate  maintenance  functions,  as  shown  in 
Exhibit  IV-7. 

Eighty-three  percent  of  the  Group  I  companies  separated  maintenance 
functionally. 

Only  20%  of  the  groups  II,  III  and  IV  companies  separated  development 
from  maintenance. 

The  one  respondent  in  Group  I  that  said  maintenance  was  not  a  separate 
function  was  part  of  a  relatively  new  and  small  department. 

That  interview  also  stated  that  maintenance  was  a  separate  function  in 
some  of  the  larger  departments  in  the  company. 
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EXHIBIT  IV-7 


NUMBER  OF  COMPANIES  RESPONDING  TO  THE  QUESTION, 
"ARE  MAINTENANCE  AND  DEVELOPMENT 
OF  SOFTWARE  SEPARATED  FUNCTIONALLY?" 


YES  NO 
GROUP  I 


YES  NO 
GROUPS  II,  III  AND  IV 
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The  separation  of  maintenance  from  development  did  seem  to  be  partly 
a  function  of  size  and/or  expected  longevity  of  the  software  develop- 
ment group's  product. 


Many  of  the  companies  that  did  not  separate  maintenance  from  development 
felt  very  strongly  that  it  was  beneficial  to  combine  the  functions  for  the 
following  reasons: 

Maintenance  was  often  considered  to  be  a  lower-level  or  less  desirable 
job  than  development,  and  it  was  felt  to  be  better  for  morale  if 
everyone  shared  in  this  unpleasant  task. 

Some  felt  that  the  developer  was  best  qualified  and  most  efficient  to 
maintain  the  product. 

One  of  the  Group  I  companies  addressed  the  issue  of  lower  job  status  for 
maintenance  by  rotating  all  personnel  from  maintenance  to  development  and 
back  again. 

The  separation  of  the  two  functions  was  overwhelmingly  favored  by  the  more 
successful  companies,  and  is  probably  a  factor  in  their  success,  because: 

A  development  group  that  does  not  have  maintenance  responsibility  is 
less  subject  to  interruptions. 

The  skills,  talents  and  personality  traits  are  different  for  good  mainte- 
nance people  and  good  development  people. 

The  activities  are  sufficiently  different  to  benefit  from  different 
management,  control  and  measurement  techniques. 

The  separation  of  the  two  functions  requires  much  better  specifications 
and  documentation. 
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Maintenance  personnel  have  a  broader  base  of  experience  in  dealing 
with  a  variety  of  problems,  especially  when  a  new  product  is  released, 
because  they  will  have  seen  similar  problems  in  older  products. 

All  of  the  companies  surveyed  were  asked  to  separate  their  development  and 
maintenance  personnel  by  analyst  or  programmer  function,  and  to  report  the 
number  of  people  in  each  activity. 

A  very  large  percentage  of  the  companies  reported  that  they  did  not 
distinguish  between  the  functions  of  analyst  and  programmers  because 
most  of  their  people  did  both. 

Only  3  of  the  21  companies  (14%)  could  report  on  the  functions 
separately,  as  shown  in  Exhibit  IV-8. 

Several  of  the  companies,  especially  those  engaged  in  the  development  of 
microprocessors,  make  very  little  distinction  between  software  and  hardware 
engineers. 

So  much  software  is  being  developed  in  hardware  to  yield  firmware  that 
development  personnel  have  to  be  qualified  in  both  hardware  and 
software  development. 

In  one  of  the  Group  I  companies,  individuals  were  assigned  hardware 
development  positions  who  had  no  formal  training  in  college  in  that 
function. 

Although  the  total  number  of  people  dedicated  to  maintenance  for  companies 
who  reported  this  breakdown  was  greater  than  the  number  of  people  dedicated 
to  development,  the  average  company  had  more  personnel  assigned  to  devel- 
opment than  to  maintenance. 

A  surprising  73%  of  the  more  than  4,000  software  personnel  could  not  be 
accounted  for  as  either  development,  maintenance,  analyst  or  programmer. 
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The  Group  1  companies  were  able  to  provide  more  detail  on  this  subject 
than  any  of  the  other  groups. 

B.       INTERDEPARTMENTAL  RELATIONSHIPS 

•  The  companies  were  asked  to  rate  the  quantity  and  effectiveness  of  commu- 
nications between  software  development  and  other  departments  on  a  scale  of  I 
to  5,  where  I  is  the  smallest  quantity  and  least  effective,  and  where  5  is  the 
highest  quantity  and  most  effecitve.  A  total  rating  was  then  developed  by 
multiplying  the  two  ratings  together  and  taking  the  square  root  of  the  results. 

•  Group  IV  consisted  of  only  two  companies,  one  of  which  had  a  total  number  of 
20  employees  who  "all  talked  with  each  other,"  so  it  was  not  included  in  this 
analysis. 

•  Exhibit  IV-9  indicates  that  the  overall  effectiveness  of  communications 
between  the  software  development  department  and  all  other  departments 
might  be  an  important  factor,  since  the  higher-rated  groups  appear  to 
communicate  progressively  better.  However,  the  resultant  ratings  are  so  close 
that  one  cannot  draw  a  firm  conclusion  from  them. 

•  An  examination  of  communications  wth  eight  different  departments  yields 
some  more  conclusive  information. 

The  highest-level  and  most  effective  communications  were  with  the 
software  mainframe  and  hardware  development  for  all  three  groups  of 
software  development  organizations,  as  shown  in  Exhibit  IV- 10. 

The  interface  with  product,  market  and  business  planning  was  much 
more  effective  among  Group  I  companies  than  among  Group  II  and  III 
companies. 
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EXHIIT  IV-9 


RESPONDENT  SELF-RATINGS  OF  ALL  COMMUNICATIONS 
FOR  ALL  COMPANIES  BY  GROUPS 
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•  INPUT  has  observed  that  the  effectiveness  of  the  software  development 
department  is  very  dependent  upon  good  communications  with  the  end  user. 

•  The  communications  with  the  end  user  were  reinforced  in  the  most  successful 
organizations  by: 

Imparting  to  the  software  personnel  the  importance  of  sales  and  profits 
from  the  products  they  developed. 

Establishing  that  the  end  users,  and  the  sales  force  that  serves  them, 
are  the  software  department's  customers  and  responsibility. 

Clearly  defining  the  goals  and  mission  of  the  company  and  the 
important  role  that  software  development  had  in  attaining  the  goals  and 
fulfilling  the  mission. 

Emphasizing  that  budgets  and  schedules  were  very  important,  but  not  as 
important  as  a  superior  product  and  a  happy  customer. 

•  Communications  with  the  planning  departments  are  important  not  only  in 
resolving  marketing  and  technical  problems,  but  in  solving  problems  and 
providing  needed  solutions  to  the  customer. 

•  The  surveyed  companies'  suggestions  for  improving  interdepartmental  commu- 
nications are  shown  in  Exhibit  IV- 1  I. 

C.       ORGANIZATIONAL  CHANGES 

•  Most  of  the  companies  surveyed  were  growing  rapidly,  and  growth  was  the 
principal  force  causing  organizational  changes. 
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EXHIBIT  IV-n 


SURVEYED  COMPANIES'  SUGGESTIONS  FOR 
INTERDEPARTMENTAL  COMMUNICATIONS 
IMPROVEMENTS  BY  GROUPS 


CROUP  I 

"More  communications  in  and  before  specification  process." 
"Rotate  people  between  marketing  and  programming." 

"Expose  development  people  more  to  customer  sites  so  they  can  see  problem." 
"Establish  procedures  to  resolve  differences  between  marketing  and  software 

developing  regarding  priorities." 
"Need  to  communicate  more  in  memos  about  problems  in  early  stages  before 

they  become  a  big  deal." 
"Communications  between  marketing  and  software  development  must  be 

improved  regarding  objectives  and  priorities." 

GROUP  II 

"A  recent  re-organization  has  disrupted  communications." 

"Status  reports  between  groups  should  be  more  consistent." 

"More  meetings  and  presentations." 

"Plan  specific  meetings  to  discuss  issues." 

"We  need  more  technical  expertise  at  executive  level." 

"Marketing  is  doing  too  much,  going  beyond  their  roles." 

GROUP  III 

"Follow  procedures,  write  specifications  and  have  formal  signoffs." 
"Prior  to  commencement  of  a  project,  identify  all  the  people  that  will  be 

relevant  to  it  and  include  them  on  an  official  list  of  who  should 

receive  information." 
"More  frequent  and  regular  meetings  with  published  minutes  of  various 

development  groups  -  its  done  only  quarterly  now." 
"Physical  location  is  a  problem.  Marketing  and  software  are  in  two  different 

towns. " 

GROUP  IV 

"We're  only  twenty  people  (entire  company).  We  talk  to  each  other  all  the  time. 
"As  we  get  bigger  it  will  be  a  problem." 

"That  relates  to  understanding  mechanisms  for  handling  common  objectives." 
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Many  of  the  changes  were  toward  more  functional  specialization  as  the 
organizations  grew. 

But  there  was  a  very  clear  effort,  to  maintain  the  project  orientation  of 
the  software  development  department,  which  was  more  successful  with 
the  Group  I  companies. 

Restructuring  into  divisions  or  lines  of  business  was  also  utilized  to 
maintain  the  project  structure. 

As  organizations  grow,  they  often  establish  an  advanced  development  team  for 
new  product  development. 

The  larger,  more  successful  organizations  often  establish  a  separate,  and 
sometimes  very  high  level,  quality  assurance  department. 

The  creation  of  a  publications  and/or  documentation  group  within  each  product 
group  seems  to  contribute  to  the  productivity  of  software. 

The  organizational  distance  between  hardware  engineering  and  software  engi- 
neering is  becoming  an  important  factor  in  developing  good  products. 

The  closer  hardware  and  software  engineering  work  together,  the  better 
the  products. 

As  the  software  organization  gets  larger,  it  becomes  more  important  to  have  a 
product  planning  function  in  the  group  that  contains: 

Marketing  personnel. 

Software  engineers. 

Hardware  engineers. 
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Business  planners. 

Whether  large  or  small,  companies  appear  to  produce  better  software  products 
when  they  do  not  report  to  marketing. 

Although  most  companies  functionally  separate  systems  from  applications 
software  development  as  they  grow  larger,  some  of  the  most  successful 
companies  maintain  very  close  interfaces  between  these  functions.  Rotating 
personnel  between  these  groups  could  be  beneficial. 

Matrix  organizations  should  only  be  attempted  by  very  mature  organizations 
with  proven  and  stable  management  -  and  only  as  a  last  resort. 
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SOFTWARE  DEVELOPMENT  COST  AND  FINANCIAL  RATIOS 


A  number  of  questions  about  software  developnnent  cost  were  asked  in  the 
interview,  but  very  little  meaningful  information  was  provided  by  respondents. 

As  mentioned  earlier,  the  data  provided  on  cost  per  line  and  lines  per  person 
month  turned  out  to  be  of  little  use. 

Enough  data  were  provided  on  software  development  and  maintenance  cost  as 
a  percent  of  hardware  development  cost  to  determine  that  it  is  approximately 
200%,  as  shown  in  Exhibits  V- 1  through  V-5. 

Respondents  reported  that  the  cost  of  software  development  was  approxi- 
mately three  times  as  high  as  the  cost  of  software  maintenance,  which 
conflicts  with  the  relatively  equal  number  of  people  assigned  to  those 
functions,  as  shown  in  Exhibit  IV-8. 

This  difference  is  probably  due  to  the  fact  that  many  of  the  develop- 
ment groups  interviewed  were  involved  more  in  new  product 
development  than  in  well-established  products. 

INPUT  estimated  that  on  estabished  products,  maintenance  requires 
about  60%  of  the  software  budget. 

A  number  of  the  respondents  did  not  know  if  they  should  classify  enhancement 
to  a  product  as  maintenance  or  as  development. 
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Other  respondents  found  it  difficult  to  distinguish  between  sustenance  and 
enhancement. 

Still  others  indicated  that  the  product  development  was  a  continuing  process. 

It  is  suspected  that  some  of  the  expenditures  for  software  development  and 
maintenance  per  employee  per  year  were  unburdened,  while  others  were 
burdened,  which  jeopardizes  the  accuracy  of  the  information. 

Regional  difference  in  pay  scale  also  affected  this  number. 

Perhaps  one  of  the  most  meaningful  observations  derived  from  these  responses 
was  the  respondents'  varying  ability  to  answer  questions  on  software  develop- 
ment cost  and  productivity. 

To  derive  the  percent  of  questions  that  could  be  answered,  the  number 
of  answers  was  divided  by  the  number  of  questions  on  software 
development  cost  and  productivity  for  each  group. 

The  Group  I  companies  were  able  to  answer  63%  of  the  questions  as 
compared  to  44%  from  all  of  the  companies  combined,  as  shown  in 
Exhibit  V-6. 

It  seems  that  the  better  one  is  informed  about  one's  business,  the  more 
effectively  one  can  run  it. 

The  companies  who  rated  lower  on  the  scale  of  1  to  4  were  less 
concerned  about  the  cost  of  doing  business. 

Exhibit  V-7  shows  the  individual  respondents'  answers  to  the  question  ad- 
dressing percent  of  total  software  budget  expended  on  the  maintenance 
function. 
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EXHIBIT  V-6 


PERCENT  OF  RESPONSES  MADE  BY  GROUPS 
TO  QUESTIONS  ON  SELECTED  FINANCIAL  DATA 
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EXHIBIT  V-7 


PERCENT  OF  TOTAL  SOFTWARE  BUDGET 
EXPENDED  ON  MAINTENANCE  FUNCTION 
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One  would  expect  Group  I  to  respond  better  to  this  question  since  a 
much  higher  percentage  of  these  companies  provided  maintenance  as  a 
function  separate  from  development. 

But  even  so,  one  would  expect  more  than  27%  of  the  Group  II,  III  and  IV 
respondents  to  be  aware  of  maintenance  cost. 

There  was  no  significant  difference  in  the  amounts  expended  on  the 
maintenance  function  between  Group  I  and  all  other  groups. 
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STANDARDS  AND  QUALITY  CONTROL  IN  SOFTWARE  DEVELOPMENT 


A.       PROGRAMMING  STANDARDS 

•  One  of  the  most  startling  findings  in  tiiis  study  is  that  there  may  not  be  a 
correlation  between  the  use  of  programming  standards  and  the  effective 
development  of  software.  This  finding  conflicts  with  other  findings  in  the 
study  and  with  generally  accepted  ideas.  It  raises  some  interesting  questions 
that  should  be  explored  further. 

•  The  surveyed  companies  were  asked  if  they  used  programming  standards. 

Seventeen  responded  "yes,"  and  4  responded  "no." 

The  group  responding  "yes"  was  nearly  equal  between  the  companies  in 
Group  I  and  the  combined  companies  in  Groups  11,  III  and  IV. 

•  The  companies  were  not  given  a  definition  of  programming  standards. 

Each  company  was  permitted  to  interpret  the  term  as  it  preferred. 

It  is  safe  to  assume  that  each  company  used  the  term  in  the  context  of 
its  own  software  work,  and  the  interpretation  was  likely  to  differ  from 
company  to  company. 
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The  companies  were  also  asked  to  rate  the  effectiveness  and  level  of 
adherence  to  those  standards  on  a  scale  of  I  to  5,  where  1  is  the  least 
effective  or  lowest  level  of  adherence  and  5  the  most  effective  or  highest. 

The  ratings  shown  in  Exhibit  VI- 1  show  an  inverse  correlation  to  the  effec- 
tiveness of  the  software  development  effort. 

The  inverse  correlation  may  not  hold  any  true  significance  for  several  reasons: 

The  standard  error  of  deviation  is  greater  than  any  of  the  variations 
shown  in  the  exhibit. 

If  the  companies  who  had  no  standards  were  not  excluded,  but  rather 
assigned  ratings  of  1  because  they  did  not  employ  standards,  then  the 
inverse  correlation  would  probably  disappear. 

Effective  standards  may  not  contribute  to  productivity  for  several  reasons: 

Standards  limit  the  creative  process,  and  software  development  is  a 
creative  process. 

Standards  are  virtually  mandatory  for  large  development  projects, 
which  are  often  less  efficient  than  smaller  ones.  However,  there  is  no 
indication  that  standards  per  se  lead  to  efficiency. 

Any  loss  in  efficiency  and  productivity  in  the  development  process  due  to 
standards  may  be  acceptable  in  light  of  future  savings  in  software  maintenance. 

Most  of  the  Group  1  companies  had  separate  maintenance  groups,  which 
require  higher  standards. 

An  overwhelming  majority  of  Groups  II,  Ml  and  IV  companies  did  not 
separate  maintenance  from  development. 
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These  companies'  ratings  of  standards  may  be  significantly  affected  by 
their  need  for  them,  and  so  may  not  be  very  meaningful  when 
comparing  between  groups. 

•  The  primary  thing  to  be  learned  from  these  findings  is  that  the  effect  of 
standards  on  productivity  should  probably  be  examined  more  closely. 

•  The  companies'  responses  to  the  question,  "If  you  have  standards,  how  do  you 
measure  the  level  of  adherence  to  those  standards?"  are  shown  in  Exhibit  VI-2. 

From  Group  I  to  Group  III,  the  statements  become  somewhat  more 
quantitative. 

B.       QUALITY  CONTROL 

•  The  surveyed  companies  were  asked  how  they  measured  the  quality  of 
software  development  and  what  type  of  quality  control  mechanisms  they 
employed. 

•  The  level  of  quality  control  employed  by  each  company  was  evaluated  by 
counting  the  number  of  specific  quality  control  measures  mentioned  by  the 
respondents  to  the  various  questions  in  Section  4  of  the  questionnaire. 

•  The  average  number  of  measures  mentioned  for  each  group  is  shown  in  Exhibit 
VI-3. 

•  A  high  level  of  quality  control  is  associated  with  the  Group  I  companies,  with 
much  lower  levels  for  the  other  three  groups. 

•  A  high  level  of  quality  control  is  extremely  important  to  effective  software 
development. 
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EXHIBIT  VI-2 

RESPONSES  TO  THE  QUESTION, 

■'IF  YOU  HAVE  STANDARDS,  HOV;  DO  YOU 

MEASURE  THE  LEVEL  OF  ADHERENCE  TO 
THOSE  STANDARDS?" 


GROUP  1 

"Don't  formally  measure,  informal  process,  peer  pressure." 

"Right  now,  on  feeling  -  we  get  bitten  and  then  we'll 
talk  to  someone  involved." 

"Measure  through  checkpoints  throughout  development 
process" 

GROUP  II 

"Code  reviews  and  design  reviews." 

"I  just  know  over  95%  follow  standard." 

"By  testing  -  they  just  are,  they're  obvious,  functional 
and  that's  the  way  it  is." 

"By  examining  program  structures  that  we  see." 

"Spot  checking." 

GROUP  III 

"No  formal  measure-problem  resolution  tells  about  it. 
Structured  programming  enforced  by  the  languages 
and  others  by  management." 

"New  people  coming  in  have  not  been  given  training  to 
indoctrinate  them  in  the  standards.  We  rely  on  people 
to  do  it  themselves  -  no  policing." 

"Integration  good,  maintenance  good." 

"Certain  people  watch  this.  Software  library  will  review 
adherence  and  issue  part  number  or  it  doesn't  be- 
come a  product." 

"Project  managers  know  coding  and  how  program  is 
coded. " 


NOTE:  GROUP  IV  HAD  NO  RESPONSES 


COMPANY  A 
COMPANY  C 

COMPANY  D 

COMPANY  L 
COMPANY  M 

COMPANY  N 

COMPANY  0 
COMPANY  P 

COMPANY  H 

COMPANY  I 
COMPANY  K 
COMPANY  Q 

COMPANY  T 
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EXHIBIT  VI-3 
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A  quality  assurance  department  that  reports  to  high-level  management  and  is 
separate  from  the  software  development  department  was  often  found  in  the 
more  successful  companies. 

These  companies  also  usually  combined  hardware  and  software  quality 
control. 

The  companies'  responses  to  the  question,  "How  do  you  measure  the  quality  of 
your  software  development?"  are  shown  in  Exhibit  VI-4. 

The  companies  in  Group  I  generally  employed  effective  measures  that  were: 

Quantitative. 

Scientific. 

Statistical. 

Historical. 

Predictive. 

Similar  measures  were  also  cited  when  asked  "What  type  of  quality  control 
mechanisms  do  you  employ?"  as  shown  in  Exhibit  VI-5. 

The  more  successful  companies  closely  related  quality  control  to  revenues  and 
profits. 

Establishing  goals,  in  addition  to  measures,  for  quality  control  is  also  an 
important  factor. 

When  asked  what  procedural  improvements  they  would  recommend  for 
increasing  software  product  quality,  the  companies  responded  as  shown  in 
Exhibit  VI-6. 
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EXHIBIT  VI-4 
RESPONSES  TO  THE  QUESTION, 
"HOW  DO  YOU  MEASURE  THE  QUALITY  OF 
YOUR  SOFTWARE  DEVELOPMENT?" 


GROUP  1 

COMPANY 

A 

A 

"Statistics.  Bug  rate  per  1  ,000  hours  of  use.  Product 
team  puts  test  plan  together  to  test  all  features. 
Bugs  per  installation  per  year.  Weight  bugs  for 
severitv  of  oroblem." 

COMPANY 

B 

.-       ■              "  ■) 

"No  measures. " 

COMPANY 

C 

"A  problem  because  the  emphasis  is  on  profits.  Trying 
to  develop  a  test  bed  and  regression  test  bed  for 
each  Drodijpt     Trvinn  tn  fvptrlc  f^Wuva  »-atck  r\f  ^4XRC  n 

COMPANY 

D 

"Internal  procedures.  Maintain  statistics  on  problems. 
Mean  time  ooeratina  statistics.  Establish  nnal<;  and 
measure  performance  relative  to  goals.  Monitor  problems. 

COMPANY 

E 

"If  the  developer  says  it  works.  If  it  satisfies  the  customer. 
Try  to  use  predictors  rather  than  measures." 

COMPANY 

F 

"Customer  complaints  about  bugs." 

GROUP  II 

COMPANY 

G 

"It  works  -  performance." 

COMPANY 

L 

"Methodology,  milestones."  "Bug  level/severity." 

COMPANY 

M 

"Are  there  bugs?  Is  it  competitive?  Q/C  techniques  - 
Quality  assurance   specifications  by  design  team. 
How  well  it  sells. " 

COMPANY 

N 

"Usability  is  directly  related  to  quality."  "Multiple 
installations  by  dealers."  "If  it  functions." 

COMPANY 

0 

"In  relationship  to  how  well  hardware  functions  using 
software;  how  well  it  compares  to  other  software  on 
market.  How  well  it  accomplishes  its  objective.  Response 
from  distributors." 

COMPANY 

P 

"We  don't  have  any  quantitative  measures.  V/ith  great 
difficulty. " 
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EXHIBIT  VI-4  (CONT.) 
RESPONSES  TO  THE  QUESTION, 
"HOW  DO  YOU  MEASURE  THE  QUALITY  OF 
YOUR  SOFTWARE  DEVELOPMENT?" 


GROUP  III 


COMPANY  H 

COMPANY  I 
COMPANY  K 

COMPANY  Q 


COMPANY  R 


COMPANY  S 


COMPANY  T 


COMPANY  J 
COMPANY  U 


"Market  acceptance  of  the  product."  "Budgets  are  not  a 
constraint  because  it's  such  a  small  part  of  total  cost." 
"Schedules  are  important." 

"We  have  a  test  and  maintenance  group  that  do  alpha  and 
beta  test.  Customer  acceptance." 

"If  it's  on  time  and  on  budget."  "If  it  functions." 
"Customer  acceptance." 

"Does  it  function  in  regards  to  the  documentation  and 
internal  specifications?"  "Quality  of  external  (user) 
documentation."  "Efficency  of  performance." 
"Modularity,  reliability." 

"Release  for  alpha  test  -  get  results."  "Try  to  fix  bugs 
on  next  release,  no  more  than  six  weeks."  "Sample 
programs,  regression  tests."  "Customer  exercises 
product    before  it's  handed  over  to  end  user." 

"If  it  works  and  supports  people  in  doing  what  they 
have  to  do." 

"Good  reports  from  the  field." 

GROUP  IV 

"Whether  it  performs  the  function  the  user  needs.  Is 
it  timely?  Can  it  be  delivered  by  someone  other  than 
the  inventor?" 

"Customer  satisfaction." 
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EXHIBIT  VI-5 

RESPONSES  TO  THE  QUESTION, 
"WHAT  TYPE  OF  QUALITY  CONTROL 
MECHANISM  DO  YOU  EMPLOY?" 


GROUP  I 

COMPANY 

B 

"Quality  assurance  test  it." 

COMPANY 

C 

"Test  bed. 

Test  programmer  support. 
Require  detailed  design  specs. 
Final  test  and  approval  (handoff)." 

COMPANY 

E 

"Audit  internal  mechanism. 
Internal  procedures. 
Walk-throughs. 
Read  code. 

Impose  discipline  in  development  process." 

COMPANY 

F 

"New  product  reviews  based  on  specification." 

GROUP  II 

COMPANY 

L 

"Methodology,  acceptance  testing,  maintenance  reports." 

COMPANY 

N 

"Primarily  adequate  testing.  In-house  testing  of  everything 
before  release.  At  least  two  dealers  field  test  and 
feedback  results  to  us." 

COMPANY 

P 

"They  are  all  new.  They  are  starting  to  work.  We  use 
a  specific  quality  assurance  person." 

GROUP  III 

COMPANY 

K 

"Maintainable  and  reliable." 

COMPANY 

Q 

"Prototype  functional  test  by  quality  assurance.  Quality 
assurance  is  involved  from  bread  board  stage  to  full 
production.  Schedule  and  plans." 

COMPANY 

R 

"In-house  we  do  alpha  test.  V/e  have  a  formal  quality 
control  group.  We  perform  regression  test." 

COMPANY 

S 

"1  look  at  stuff  and  say  how  it  should  be  done.  Do 
things  myself.  Developing  a  style  book." 

COMPANY 

T 

"We  work  closely  with  marketing.  Going  through  a  design 
phase.  There  is  tight  control.  Try  to  meet  marketing 
specification.  Quality  assurance  systems  and  sign- 
off  procedures." 
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EXHIBIT  VI-5  (CONT.) 


RESPONSES  TO  THE  QUESTION, 
"WHAT  TYPE  OF  QUALITY  CONTROL 
MECHANISM  DO  YOU  EMPLOY?" 


GROUP  IV 


COMPANY  J 
COMPANY  U 


"Family  of  acceptance  and  regression  tests.  Each 
generation  is  run  against  these  tests." 

"None." 
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EXHIBIT  Vl-6 


RESPONSES  TO  THE  QUESTION, 
"WHAT  PROCEDURAL  IMPROVEMENTS  WOULD 
YOU  RECOMMEND  FOR  INCREASING  SOFTWARE 
PRODUCT  QUALITY?" 


GROUPS 

RECOMMENDATIONS 

1  U  1  AL 

GROUP 
1 
1 

GROUP 
1 1 

GROUP 

1 1 1 
1 1 1 

GROUP 
1  V 

IMPROVE  INTERFACE  BETV/EEN 
SPECIFICATION  AND  DESIGN 

1 

POLICE  SPECIFICATIONS 

3 

1 

2 

— 

— 

WRITTEN  SPECIFICATIONS  OR 
GUIDELINES 

2 

1 

BETTER  DEFINITION  OF  INTEGRA- 
TION AND  HAND-OFF  PROCEDURES 

2 

1 

DEVELOP  MORE  DEVELOPMENT  TOOLS 

3 

3 

- 

- 

MORE  REGRESSION  TESTING 

DEVELOP  SELF-TESTING  SOFTWARE 

USE  FEATURE  FUNCTION  TEST 

- 

- 

IMPLEMENT  STANDARDS 

2 

; 

1 

1 

IMPROVE  DOCUMENTATION 

MOTIVATIONAL  TRAINING  FOR 

MANAGERS 

IMPROVE  ENVIRONMENT 

CHECKS  AND  BALANCES  FOR 
PRODUCT  RELEASE 

1 

IMPLEMENT  PROFITSHARI NG 

USE  A  HIGHER-LEVEL  LANGUAGE 

PAY  OVERTIME 

MULTIPLE  REVIEW  AT  ALL  STAGES 

1 

1 
1 

1 

IMPROVE  PRODUCT  DEFINITION 
IN  MARKETING  GROUP 

2 

2 

STRONGER  QUALITY  ASSURANCE 

2 

2 

TOTAL 

27 

1  4 

7 

4 

2 
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•  The  most  frequently  mentioned  recommendation  involved  improving  specifi- 
cations or  the  specification  process. 

•  Improvements  in  quality  assurance  were  also  frequently  mentioned. 

•  Several   companies  suggested  that  implementing  standards  would  improve 
product  quality. 

C       MEASURES  OF  SOFTWARE  DEVELOPMENT  SUCCESS 

•  The  companies  indicated  that  they  measured  software  development  success 
and  failure  in  more  than  20  different  ways,  as  shown  in  Exhibit  VI-7. 

•  The  most  common  measures,  in  order  of  frequency,  were: 

Product  developed  on  schedule. 
Customer  acceptance  of  product. 
Product  works. 

Product  was  developed  within  its  budget. 
Product  had  high  sales  volume. 
Product  meets  specifications. 

•  Many  of  the  measures  mentioned  were  not  measures  of  a  successful  product 
but  of  the  product  development  process. 

•  The  more  successful  companies  in  Group  I  tended  to  measure  the  product  more 
than  the  process. 
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EXHIBIT  VI-7 


RESPONSES  TO  THE  QUESTION, 
"HOW  DO  YOU  MEASURE  SOFTWARE  DEVELOPMENT 
SUCCESS  AND  FAILURE?" 


NUMBER 
REPORTING 

OF  RESPONDENTS 
THIS  MEASUREMENT 

MEASURE  OF 
SUCCESS  AND  FAILURE 

1  U  I  AL 

GROUP 

1 
1 

GROUP 
1 1 

GROUP 
1  [  1 

GROUP 
!  V 

DEVELOPED  ON  SCHEDULE 

11 

4 

1 

5 

1 

CUSTOMER  ACCEPTANCE 

9 

2 

1 

5 

1 

PRODUCT  FUNCTIONS 

7 

2 

1 

3 

1 

DEVELOPED  ON  BUDGET 

5 

2 

1 

2 

— 

SALES  VOLUME 

5 

2 

1 

2 

PRODUCT  MEETS  SPECIFICATIONS 

4 

1 

2 

1 

LEVEL  OF  MAINTENANCE 

3 

1 

1 

1 

PRODUCT  PERFORMANCE 

2 

1 

1 

IN-HOUSE  TESTING 

2 

2 

SALES  FORCE  REACTION 

2 

1 

1 

ACCURATE  FORECAST  OF  EFFORT 

1 

1 

— 

QUALITY  OF  CODE 

1 

DOCUMENTATION  AVAILABLE 

1 

\ 

- 

- 

- 

GOOD  DOCUMENTATION 

1 

PRODUCT  OBSOLETE  BEFORE  RELEASE 

1 

FORECASTED  PROBLEM  RATE 

VERSUS  ACTUAL  PROBLEM  RATE 

1 

RETURN  ON  INVESTMENT 

1 

NUMBER  OF  INSTALLATIONS 

1 

1 

RELIABILITY 

1 

1 

NO  SEVERE  CUSTOMER  PROBLEMS 

1 

1 

NUMBER  OF  COMPLAINTS 

1 

1 

PROGRAMMER  SATISFIED 

1 

1 

TOTAL 

62 

21 

13 

25 

3 

-  84- 


INPU' 


Group  I  companies  were  concerned  about  the  most  important  measures  of 
product  success,  which  were: 

Return  on  investment  in  the  software  product. 

Customer  satisfaction  as  indicated  by: 

Increased  sales. 

Number  of  installations. 

Number  of  customer  complaints. 

The  companies  were  asked,  "What  software  development  successes  and  failures 
have  you  experienced  within  the  last  five  years?" 

Their  responses  were  analyzed  to  determine  the  reasons  behind  the 
successes  and  failures,  as  shown  in  Exhibit  VI-8. 

In  sum,  the  important  and  most  frequently  cited  reasons  for  success  were: 

Having  well-conceived  and  complete  specifications: 

Which  came  through  good  planning  and  communications  with  end 
users  and  all  persons  in  the  company  who  would  come  in  contact 
with  the  product. 

Producing  a  thorough  and  well-designed  product. 

Good  controls  by  management  throughout  the  development  process 
from  initial  needs  assessment  of  prospective  customers  to  final  delivery 
and  maintenance  of  the  product. 
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EXHIBIT  Vl-8 


REASONS  FOR  SOFTWARE  DEVELOPMENT  SUCCESSES 
AND  FAILURES  IN  PAST  FIVE  YEARS 


GROUPS 

REASONS 

TOTAL 

1 

II 

III 

IV 

WELL  CONCEIVED  AND  COMPLETE 
SPECIFICATIONS 

6 

3 

2 

1 

THROUGH,  WELL-DESIGNED  (NOT 
OVER-DESIGNEDl  PRODUCT 

3 

1 

OUT  OF  TOUCH  WITH  -  /, 
MARKETPLACE 

3 

1 

2 

CHANGES  IN  SPECIFICATIONS 

1 

- 

1 

COMPETENT  DEVELOPMENT  PEOPLE 

1 

COMPETENT  MANAGEMENT  PEOPLE 

1 

TOO  MANY  PEOPLE 

1 

SELECT  RIGHT  PEOPLE  FOR  JOB 

1 

DEMAND  HIGH  PERFORMANCE 

1 

GOOD  CONTROL  OF  DEVELOPMENT 

1 

1 

USE  OF  DEVELOPMENT  TOOLS 

•! 
1 

TOO  MUCH  FUNCTIONALITY 
IN  THE  HARDWARE 

1 

FORCED  TO  USE  POOR  (PARENT 
COMPANY'S)  HARDWARE 

1 

TOTAL 

25 

10 

8 

6 

1 
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Good  software  people  and  good  management  people  were  cited  as 
making  the  difference  in  many  cases. 

It  takes  good  people  to  attract  and  hold  good  people. 

It  takes  a  few  good  people  to  produce  software,  not  a  large 
team. 

Contact  with  end  users  is  probably  the  single  most  important  reason  for 
software  development  success. 

It  was  evident  in  all  of  the  most  effective  software  development 
groups  that  personal  contact  with  the  customer  was  a  vital 
ingredient  in  their  success. 

It  helped  the  software  people  better  understand  the  customer's 
problem. 

It  was  a  constant  reminder  of  why  the  software  people  were 
doing  what  they  were  doing. 

The  top  companies  depended  heavily  on  ego  motivators  for  their 
software  development  people.  They  did  this  through: 

Providing  means  for  the  software  people  to  experience  the  user's 
appreciation  of  their  work. 

Establishing  an  environment  which  fostered  an  identification 
with  the  product  by  the  software  development  people. 

Corporate  recognition  of  the  contributions  made  to  company 
revenue  and  profit  goals  by  the  software  products  and  their 
developers. 
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The  most  frequent  reasons  for  software  development  failure  were: 

The  software  developers  were  out  of  touch  with  the  marketplace. 

They  didn't  understand  the  needs  of  the  customer. 

They  didn't  know  the  nature  of  the  competition. 

Problems  In  specification  process: 

Specifications  were  either  poor,  Impossible  or  constantly  chang- 
ing. 

Specifications  were  subject  to  Inadequate  reviews. 

The  right  people  did  not  sign  off  the  specification. 
Assigning  too  many  people  to  a  project. 
Over-designing  a  product. 

Creating  a  product  too  large  for  the  hardware. 

Providing  more  product  than  the  customer  was  willing  to  pay  for. 

Lack  of  controls  by  management  throughout  the  development  process. 

Lack  of  measures  of  quality,  reliability,  maintainability,  productivity, 
profitability,  schedules,  budgets  and  customer  acceptance. 

Lack  of  sign-offs  and  reviews  at  all  stages  of  development,  which 
involved  all  personnel  who  had  anything  to  do  with  the  product. 
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VII    THE   FUTURE   OF    SOFTWARE  DEVELOPMENT 


THE  FUTURE  OF  SOFTWARE  DEVELOPMENT 


The  companies  were  asked  which  software  development  methodologies  they 
envisioned  being  available  by  1985  and  which  ones  they  expected  to 
implement.  Most  companies  gave  the  same  responses  to  both  questions, 
indicating  that  they  planned  to  implement  everything  they  expected  to  be 
available. 

Since  many  of  the  companies  interviewed  were  leading-edge  developers  of 
computer  systems,  they  were  often  well  on  the  way  to  implementing  many  of 
the  methodologies  for  their  advanced  systems. 

The  most  frequently  mentioned  methodologies  are  shown  in  Exhibit  VII- 1  in 
order  of  frequency. 

The  most  likely  methodology  to  be  available  will  be  computer  systems  and 
software,  which  in  effect  write  their  own  software  under  the  general  direction 
of  the  end  user. 

Much  of  the  software  will  be  incorporated  into  the  hardware  as  firmware. 

The  computers  and  people  will  write  programs  in,  or  similar  to,  PASCAL  and 
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EXHIBIT  Vll-1 

SOFTWARE  DEVELOPMENT  METHODOLOGY  RESPONDENTS 
ENVISION  BEING  AVAILABLE  BY  1985 


GROUPS 

TYPE 

DECRIPTION 

TOTAL 

1 

1 1 

III 
1 1 1 

IV 

TOOLS  FOR  LINKING  DEVELOPMENT 

1 

1 

- 

- 

- 

AND  MAINTENANCE 

MORE  PROGRAMMING  TOOLS 

2 

1 

- 

1 

- 

PRO- 

SOFTWARE LIBRARIES  OF  RE-  , 

1 

1 

3 

GRAMMING 

USABLE  CODE 

5 

TOOLS 

MORE  AUTOMATED  IMPLEMENTATION 
TOOLS  FOR  CROSS-CHECKING 

1 
1 

1 
1 

- 
— 

— 
- 

— 

TOOLS  FOR  DEVELOPING  MODULES 

1 

1 

FROM  DESIGN  SPECIFICATIONS 

SUBTOTAL 

11 

6 

1 

4 

0 

3  TO  4  COMPILERS  USING  CODE 

1 

1 

GENERATORS 

- 

HKOGKAM 
GEN- 

CD  A  TO  D  C 

PROGRAM  GENERATORS  BY  EXAMPLE 

1 

1 

— 

— 

— 

SPECIFICATION-ORIENTED  INTER- 
ACTIVE TOOLS  AND  SELF-GEN  PCS 

6 

1 

1 

4 

COMPILER  GENERATORS 

1 

— 

1 

- 

— 

MORE  PROGRAM  GENERATORS 

2 

— 

2 

— 

— 

SUBTOTAL 

11 

3 

4 

4 

0 

MORE  STRUCTURED  PROGRAMMING 

1 

2 

2 

1 

AND  DEVELOPMENT 

6 

STANDARDS 

STANDARDS  AT  LOWER  LEVELS  OF 

SYSTEMS  DEVELOPMENT 
BUILT-IN  STANDARDS  IN  LANGUAGE 

2 
1 

1 
1 

- 
— 

1 

— 

- 
— 

MULTI-USER  DEVELOPMENT  MA- 

1 

1 

CHINES  TO  ENFORCE  STANDARDS 

SUBTOTAL 

10 

3 

3 

3 

1 

HIGH-LEVEL  DEVELOPMENT 

c 

1 

1 

LANGUAGES 

LANGUAGE 

D 

3 

HIGHER-LEVEL  DEBUGGER 

1 

1 

SUBTOTAL 

6 

1 

0 

3 

2 

COMPUTERIZED  CHECKING  FOR 

1 

1 

r\       1  1 

MtN  1  A  1  I U  N 

DOCUMENTATION 
MIXED  GRAPHICS  AND  WORD  PRO- 

CESSING FOR  TECHNICAL 
DOCUMENTATION 

1 

1 

SUBTOTAL 

2 

1 

0 

0 

STUDYING  ORGANIZATIONAL 

STRUCTURES'  IMPACT  ON 

1 

1 

PRODUCTIVITY 

OTHER 

MORE  SOFTWARE  IN  HARDWARE 
EXTENSIONS  OF  FILE  MANAGEMENT 

SYSTEMS  AND  TRANSACTION 

MANAGEMENT  SYSTEMS 

2 
1 

1 
1 

1 

SUBTOTAL 

4 

1 

2 

1 

0 

GRAND  TOTAL 

44 

15 

10 

1  6 

3 
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The  languages  employed  will  have  built-in  standards  and  will  operate  on 
virtually  any  hardware  developed  in  the  1980s. 

Most  programs  will  document  themselves. 

Systems  will  have  comprehensive  built-in  diagnostics  and  repair  mechanisms 
for  both  hardware  and  software. 

Many  problems  being  addressed  will  go  beyond  human  comprehension  because 
of  the  millions  of  variables  and  parameters  being  addressed. 

The  number  of  software  people  available  will  not  be  as  critical  a  problem  as 
the  quality  of  those  people. 

By  the  1990s,  the  cost  of  software  will  come  down  relative  to  hardware  as  end 
users  are  able  to  verbally  instruct  their  machines,  which  will  eliminate  the 
programmer  from  the  development  process. 

The  machines  will  actually  be  able  to  suggest  a  number  of  alternative 
solutions  to  any  given  problem,  list  the  advantages  and  disadvantages  of 
each  option,  and  recommend  the  best  solution. 

A  likely  scenario  would  be: 

Early  1980s. 

Programming  tools. 

Software  libraries  on  chips. 

High-level  structured  programs. 


-91  - 


INPUT 


Built-in  standards. 
Mid  1 980s. 

Progrann  generators. 
Compiler  generators. 

System  generators  (software  and  hardware). 
The  i  990s. 

Automatic  software  and  hardware  designing  systems. 

Systems  completely  compatible  and  "friendly"  with  end  users. 

Literally  conversational  systems  with  significant  creative  capa- 
bilities. 
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APPENDIX  A: 


INTERVIEW  PROFILES 


APPENDIX  A:          INTERVIEW  PROFILES 


•  Anderson  Jacobson,  Inc. 

•  Apple  Computer  Inc. 

•  BRD  (Bainbridge  Research  &  Development),  inc. 

•  Centurion  Corporation 

•  Century  Computer  Corporation 

•  Display  Data  Corporation 

•  Digital  Telephone  Systems,  Inc.  (subsidiary  of  Harris  Corp.) 

•  Fairchild  Camera  and  Instrument  Corporation 

•  Four-Phase  Systems,  Inc. 

•  General  Automation 

•  Harris  Corporation  -  Computer  Systems  Division 

•  Hewlett  Packard  General  Systems  Division 

•  Mitsubishi  Electronics  (Melcom  Business  Systems) 


INPUT 


NCR 

New  England  Digital  Corporation 
Olivetti  Corporation  of  America 
Ontel 

Raytheon  Data  Systems  Company 
Tymshare,  inc. 

Western  Electric  Corporation 

Zilog  (subsidiary  of  Exxon  Corporation) 
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APPENDIX  B:  DEFINITIONS 


•  BUSINESS  UNIT  SOFTWARE  ORGANIZATION  contains  all  of  the  functions, 
or  representatives  of  the  functions,  necessary  to  produce  and  market  a  product 
(including  manufacturing,  marketing,  planning  and  quality  assurance)  assigned 
to  a  development  group. 

The  business  unit  is  supposed  to  have  all  of  the  capabilities  of  a 
company. 

This  type  was  categorized  as  a  project  organization  for  this  study. 

•  FUNCTIONAL  SOFTWARE  ORGANIZATION  is  organized  so  that  individuals 
are  assigned  to  specific  functions  that  cross  product  lines. 

•  PROJECT  SOFTWARE  ORGANIZATION  is  organized  so  that  individuals  are 
assigned  to  specific  products  and  may  perform  a  variety  of  functions  relating 
to  that  product. 

•  MATRIX  SOFTWARE  ORGANIZATION  is  organized  so  that  individuals  share 
responsibility  and/or  authority  for  developing  the  software  with  other  indi- 
viduals outside  of  the  software  development  organization. 


-95- 


INPUT 


-  96- 


APPENDIX   C:   DATA   BASE   OF  ORGANIZATIONAL 

CHARTS 


APPENDIX  C: 


DATA  BASE  OF  ORGANIZATIONAL  CHARTS 


•         The  organizational  charts  are  presented  in  alphabetical  order. 

Charts  A  through  E  are  the  five  public  Group  I  companies. 
Chart  F  is  the  private  Group  I  connpany. 

Charts  G  through  K  are  the  five  public  companies  from  Groups  II,  III 
and  IV. 

G  and  J  are  in  Group  II. 

H,  I  and  K  are  in  Group  111. 
Charts  L  through  P  are  in  Group  II. 
Charts  Q  through  T  are  in  Group  III. 
Chart  U  is  in  Group  IV. 
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EXHIBIT  C-4 
COMPANY  D 


SENIOR 
V.P. 
MARKETING 


ASSISTANT 
V.P. 
FOR 
APPLICATIONS 


TECHNICAL 
RELEASE* 


DIRECTOR 

OF 
SUPPORT 
ORGANIZATIONS 


± 


SOFTWARE 
DEVELOPMENT 
SYSTEMS 


PRODUCT 
MANAGER 


I 


SOFTWARE 
DEVELOPMENT 
SYSTEMS 


SOFTWARE 
DEVELOPMENT 
SYSTEMS 


INTERVIEWEE 
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EXHIBIT  C-5 
COMPANY  E 


PRESIDENT 


SENIOR 
EXECUTIVE 
V.P. 

ENGINEERING 


SENIOR 
EXECUTIVE 
V.P. 

ENGINEERING 


SENIOR 
EXECUTIVE 
V.P. 

ENGINEERING 


V.P. 

LEGAL 


EXECUTIVE 

V.P. 
CORPORATE 
STAFF 


EXECUTIVE 
V  P 
MANU- 
FACTURING 


EXECUTIVE 
V.P. 
SALES 
DOMESTIC 


EXECUTIVE 
V.P. 
SALES 
INTERNATIONAL 


V.P.  MANU- 
FACTURING 
GROUP  I 

V.P.  MANU- 
FACTURING 
GROUP  II 

V.P.  MANU- 
FACTURING 
GROUP  III 

V.P.  MANU- 
FACTURING 
GROUP  IV 

GENERAL 
MANAGER 
PRODUCT 
CENTER 
I 


GENERAL 
MANAGER 
PRODUCT 
CENTER 
II 


GENERAL 
MANAGER 
PRODUCT 
CENTER 


GENERAL 
MANAGER 
RESEARCH 
AND  DE- 
VELOP- 
MENT 


GENERAL 
MANAGER 
MARKETING 


GENERAL 
MANAGER 
SALES 


GENERAL 
MANAGER 
PLANNING 


DIRECTOR 
SOFTWARE* 


MANAGER 
PRODUCT  I 
SOFTWARE 
DEVELOPMENT 


MANAGER 
PRODUCT  II 
SOFTWARE 
DEVELOPMENT 


MANAGER 
PRODUCT  III 

SOFTWARE 
DEVELOPMENT 


ASSISTANT 
MANAGER 


A5SIS 

TANT 
iGER 

CHIEF 
PROGRAMMERS 

PROGRAMMERS 

*INTERVIEWEE 


ASSISTANT 
MANAGER 


-  102  - 


INPU 


o  y 

z  ^  z  z  ^1 

UJ  H  <  ^  Q.I 

ULJL      U  3 

-J  (/)  ' 


-  103- 


INPUT 


(/) 

LU 

Q  U 

C/) 

LU 

•-^ 

z 

o 

^2 

O 

(/) 

ORP 
PLAI 

DIV 

U 

H 

to 

Z 

to  LU 

z 

LU 

LU  Q. 

z 

H  O 

O 

o 

CO  _J 

LL 

>  LU 

CO  > 

o 

DE 

u 

-  104- 


1- 

I/) 

o 

LU 

Q. 

-I 

Q. 

< 

ZD 

(/) 

o 

z 

z 

LU 

H 

Wd 

KE 

o 
_] 

LU 

< 

> 

DE 

D 
Q 
O 

OL 


RE 

z 

LU  v: 

< 

S2 

o  — 

LL 

O 

CO 

I 

CL 


Z  ^ 
>  Q 


LU 


LU 


O 
Csl 
Cl 


m  2  =5 
>  y  Q 
£  ^  O 

CL 


LU 
UJ 

LU 
> 

UJ 
H 


-  105- 


INPUT 


EXHIBIT  C-9 


COMPANY  I 


PRESIDENT 


ADVANCED 
RESEARCH 
AND 
DEVELOPMENT 


DIVISION 
PRODUCT  1 


DIVISION 
PRODUCT  II 


FINANCE 


DIRECTOR 
OF 

ENGINEERING 

DIRE 
0 

SOFT 

CTOR 
F 

WARE'^ 

MARKETING 


SYSTEMS 
SUPPORT 
TESTING  AND 
MAIN- 
TENANCE 


SUPPORT 
DEVELOPMENT 


APPLICATIONS 
DEVELOPMENT 


•interviewee 


-  106  - 


I 

u 

— 

X 
m 


< 

Q. 

o 
u 


m 

LU 

LU 

> 
DC 
LU 
H 


-  107- 


INPUT 


1 

u 

> 

H 

AN 

CQ 

Q. 

O 

EX 

U 

-  108- 


INPUT 


1- 

Q 

LU 

LU 

(J 

LOP 

> 

UJ 

> 

< 

LU 

Q 

h- 

EN 

LU 

1- 

1^ 

1 

u 

U 

Q. 

Q 

z 

z 

ODU 

ELO 

ANI 

MAI 

W  M 

V  Nd 

a: 

> 

l- 

a. 

DE 

\- 

z 

LU 

1 

CE 

U 

ELOP^ 

Q 

z 

z 

ODL 

AN 

MAI 

ENA 

a: 

> 

1- 

Cl 

LU 
Q 

-  109- 


INPUT 


CO 

I 

U 

H 
CO 


< 


^  O 

X  u 


UJ 

oi 

LU 
> 

1X1 
h 
Z 


-  I  10- 


INPUT 


I 

u 

X 
LU 


< 
CL 

o 
u 


LO 

LLJ 

> 

< 

ALE 

ENT, 

LU 

en 

Q 

LU 

CL 

LU 

LU 


< 

a: 
o 

CL 

u 
< 

Z 
O 

u 

LU 
Q 

(/) 
H 
D 
O 


LU 
LU 

LU 
> 
LU 


-111- 


INPUT 


r-  O 

1 

u  > 

\- 

CQ 


< 
Q. 


X 
LU 


O 

u 


-  I  12- 


INPUT 


I 

u 

00 

X 
X 
LU 


Q. 

> 
Z 
< 

o 
u 


Lli 

m 


LU 

> 


3- 


INPUT 


u 

H 

CQ 

X 

UJ 


a 

>■ 

z 
< 

Q. 

o 
u 


- 1 14- 


INPUT 


CO 


en 


< 

CL 

n:  o 
X  u 

LLI 


CD  4: 


LU 

> 
LU 


-115- 


INPUT 


o 
z 

z 

Z) 

z 
o 

CO 

O 

Q. 
CO 
LU 
LXJ 

UJ 
> 

tr 

LU 

I- 
z 


-  I  16- 


INPUT 


o 

I 

U 

CD 


> 

Z 

< 
Q- 


X  u 

LLI 


O  ijj 

>  ^ 
:_  m 


LU 
Q 

CO 
LLI 


01 

LJJ  C/^ 


I- 


LU  O 

u  u 


LU 
I- 

> 

if) 


o 
I- 
u 

LU 


li. 
O 


z 
H 

LU 
< 


LU  ■*= 
01  OL 
<  UJ 

u.  z 

o< 


U 
Z) 
Q 
O 

CL 


-1 

< 
z 
o 


LU 
OL 
< 


H 

Z 

LU 


a. 
I-  -I 

CJ  U-  uu 

LU  O  > 
C/)  LU 


< 
Z 

o 

(/) 

LU 
U. 

o 

CL 


UJ 

u 
> 

OL 
UJ 
CO 


LLI 
< 

t- 

LL 

O 


I- 

o 

Q. 
Q. 

D 
CO 


Q. 

D 
O 
OL 
O 


UJ 
LU 

UJ 

> 

UJ 
h- 


-  1  17- 


INPUT 


o 

111 

z 

I-  ^ 

PURCHA 
AND 

UALI 

< 

LU 

ARE 
PMEN 

u 

z 

CT 

Q 

< 
z 

Z) 

LU 

Q 

1-  -I 

< 

O 

LL  ULI 

z 

PRi 

o  > 

C/)  UJ 

Q 

MA 

PRODUCT  I 
SOFTWARE 

DEVELOPMENT 
AND 

MAINTENANCE* 

PRESI 
PROPR 
HARD 
hNU  1  f 

LU 

u 

z 

< 

z 

LJL 

z 

1- 

LU 

< 

-  1  18- 


APPENDIX   D:  QUESTIONNAIRE 


CATALOG  NO.    |Y|S|U|S|  rTI 


PRACTICES  AND  PROCEDURES 
FOR  THE  DEVELOPMENT  OF  SOFTWARE 

Company  Categorization 

a.  Company  type 

I    I    Hardware  Computer  Manufacturer 
I    I    OEM  Integrator 
I    I    System  Integrator 
Software  Vendor 

b.  Software  Category 

Systems 
I    I  Communications 

Applications 
I    I    Maintenance  Only 

c.  Software  Development  Croup  Type 

I    I    New  Start-up  Company 


□ 


New  Division  or  Group  in  Existing  Company 
(1  to  3  years) 


□ New  Product  in  Existing  Company 
(3  to  5  years) 

d.      Company  Computer  Size  Orientation 

I     I    Small       ($20,  000  to  $1  00,  000  mini-computer  system) 

□ Medium    (  >  $1  00,  000  but  <  I BM  370-158) 
e.g..  Tandem 

I     I     Large       (IBM  370-158  or  larger) 
Communications 
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CATALOG  NO.    lYlSlUlSl  fl 


2.      Development  Organization 

a.      Where  and  to  whom  does  the  software  development  group  report 
in  the  organization  and  what  are  the  relationships  to  other 
functions?     (An  organization  chart  is  required  here.) 


NOTE:     Functions  should  include: 

a)  Business  Planning 

b)  Market  Planning 

c)  Product  Planning 

d)  Marketing 

e)  Sales 

f)  Hardware  Development 

g)  Marketing  Support 
(of  Field  Sales) 

h)  Software  Maintenance 

i)  Other  (define) 
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Describe  the  organization  structure  for  system  and  applications 
software  development  and  maintenance.     (Include  organization 
chart  for  software  development  and  maintenance  group,  if 
necessary.)    Are  they  separated  functionally? 

[]]]     Yes  Q  No 


CATALOG  NO.  lYjS 


2.      c.      Please  separate  your  development /maintenance  personnel  into 
the  following  categories. 


Category 

Analysts 

Programmers 

Total 

Development 

Maintenance 
(Sustaining) 

Total 
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2.      d.      Describe  your  organizational  strengths  and  weaknesses: 
Strengths:  Weaknesses: 
1)  1) 


2)  2) 


3)  3) 


e.      Please  rate  the  quantity  and  effectiveness  of  communications 
between  software  development  and  other  departments.    Use  a 
scale  of  1  to  5,  where  1  is  the  smallest  quantity  and  least 
effective,  and  where  5  is  the  highest  quantity  and  most  effective. 

Quantity  of  Effectiveness  of 

Interface  to  Department       Communications  Communications 

Business  Planning     

Market  Planning    

Product  Planning     

Marketing     

Sales     

Hardware  Development     


Marketing  Support 
(of  Field  Sales) 

Software  Maintenance 

Other  (define)  . 


f.       What  suggestions  do  you  have  for  interdepartmental  communications 
improvement? 
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1 . 

2. 

3. 
4. 
5. 


CATALOG  NO.    tYlSllllSl  FT 


3.      Software  Costs: 

*  Answer  a  and  b;  or  c     (Procure  the  requested  or  most  usable  information.) 

*a.      What  were  the  software  development  expenditures  as  a  percent 
of  company  revenues  for  the  last  fiscal  year? 

o  ■  • 

"o 


*b.      What  was  the  software  maintenance  expense  as  a  percent  of 
company  revenue  for  the  last  fiscal  year? 


% 


*c.      What  is  the  software  development/maintenance  expense  as  a  percent 
of  company  revenue?   % 

**  Answer  d  and  e;  or  f. 

**d.      What  is  the  ratio  of  software  development  expense  to  hardware 
development  expense?   

**e.      What  is  the  ratio  of  software  maintenance  expense  to  hardware 
development  expense?   

f.  What  is  the  ratio  of  software  development/maintenance  expense 
to  hardware  development  expense?   

g.  How  much  is  spent  per  employee  on  software  development  and 
maintenance? 

1)  Development  $  

2)  Maintenance  $ 


3)      Total  $ 


'h.      For  specific  products,  please  answer  the  following  questions. 

Lines  of 

Development       Year  Year  Person-Years  of  Code 

Products  Expense         Started         Completed  Effort  Expended  Produced 


-  124- 


INPUT 


CATALOG  NO.    lYISIUlSl  iTl 


4.      Software  Quality  Control 

a.      How  do  you  measure  the  quality  of  your  software  development? 


b.      What  type  of  quality  control  mechanisms  do  you  employ? 


c.  Do  you  use  programming  standards? 

[^Yes  Ono        (If  "No,"  go  to  question  n.  g.) 

d.  If  you  have  standards,  how  do  you  rate  their  effectiveness?  Use 
a  scale  of  1  to  5,  where  1  is  the  least  effective  and  5  is  the  most 
effective. 

 (Rating) 


e.      If  you  have  standards,  how  would  you  rate  the  level  of  adherence 
to  those  standards?    Use  a  scale  of  1  to  5,  where  1  indicates  the 
lowest  level  and  5  the  highest. 

 (Rating) 


f.       If  you  have  standards,  how  do  you  measure  the  level  of  adherence 
to  those  standards? 
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CATALOG  NO.    lYlSlUlSl  fl 


How  do  you  measure  software  development  success  and  failure? 
1)  Success:   


2)  Failure: 


What  software  development  successes  and  failures  have  you 
experienced  within  the  last  five  years? 


What  procedural  improvements  would  you  recommend  for  increasing 
software  product  quality? 
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5.      Software  Development  Future  Issues 

a.      What  software  development  methodology  do  you  envision  being 
available  by  1985? 


b.      What  software  development  methodology  changes  do  you  expect 
to  implement  by  1985? 


6.      Describe  the  product  or  type  of  product  for  which  you  develop 
software. 
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